[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-dev
Subject:    Re: Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT d
From:       Derek White <derek.white () oracle ! com>
Date:       2016-01-19 22:55:58
Message-ID: 569EBEFE.4060303 () oracle ! com
[Download RAW message or body]

Hi Magnus,

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.
>
> /Magnus
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.

  - Derek




[prev in list] [next in list] [prev in thread] [next in thread]