Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT during compiles?
derek.white at oracle.com
Tue Jan 19 22:55:58 UTC 2016
On 1/14/16 6:06 AM, Magnus Ihse Bursie wrote:
> On 2016-01-08 23:07, Derek White wrote:
>> [This is likely a bug, but thought I'd ask it as a question first].
>> I'm new to jdk builds on windows, and have spent way more time than
>> I'd like to admit on figuring out why my fastdebug builds did not
>> have asserts turned on.
>> The TL;DR; answer is that anyone can build this way on Windows by
>> simply executing this in cygwin before doing a make:
>> > export release="Derek is having a fun day"
>> > bash common/bin/jib.sh make -p windows-x86-debug -- images
>> (This bug has nothing to do with jib, it's just the actual command
>> line I used.)
>> This results in a build with both /D "DEBUG_LEVEL=\"fastdebug\"" and
>> /D "PRODUCT" set, because nmake.exe uppercases all environment
>> variables as it imports them (as a convenience to the user).
>> I'd think that there is no useful purpose to supporting such a
>> configuration, and it's a bug to attempt it. I suggest doing an
>> "!ifdef RELEASE" check in windows/makefiles/debug.make and
>> windows/makefiles/fastdebug.make that either errors or unsets RELEASE
>> before including vm.make.
>> Any thoughts on this? Thanks!
> In general, environment variables can have unexpected effects on the
> build, if they match a name used in the make files. There is no
> general solution to this problem.
> As for this specific problem, as Erik said in a reply to your other
> mail, we are currently working on replacing the use of nmake, so we
> are not keen on spending time fixing issues in the current nmake scripts.
> Since this problem has existed since the dawn of time (or so...), and
> it has not been reported until now, and given that there is a good
> workaround, I don't consider it worth fixing.
> I appreciate that you spent time to figure out the issue and that you
> reported it to us in such a polite manner! :-) I hope I don't come
> across as rude by dismissing your suggested fix, it's just that I want
> to spend all possible time on getting rid of nmake instead of fixing
> issues in it.
Unfortunately I ended up modifying a unix .bashrc file provided by Sun
IT back in the day to use in my cygwin env. For whatever reason Sun IT
defined the variable "release" :-(.
I am happy to see the nmake dependency go away. I'd like to make sure
that the new windows make files don't depend unnecessarily on a RELEASE
variable, but instead follow the linux/mac/solaris convention of having
the top-level make files (product/fastdebug/debug) add in the correct
options (ASSERT/PRODUCT, etc) as needed.
More information about the build-dev