OPENJDK env var not playing well with new build

[Magnus Ihse Bursie]

I think the proper way to handle this is two-fold: 
1) Make sure Makefiles only checks for variables that are explicitly set in spec.gmk
2) Detect and warn for all old-style env variables.

As for 1), it is easy to say, and relatively easy to check the existing code and fix any misses, but without automatic enforcement (which sounds hard or impossible), every change risks introducing the problem again.

As for 2), we are currently checking, in both configure and the main Makefile, for old-style env variables, and warn the user prominently. However, the check is done only for variables named ALT_*, which apparently is not an exhaustive list of old-style env variables affecting the build. It might be a good idea to extend that list to other, well-known old build  env variables, like OPENJDK. 

/Magnus

24 jan 2013 kl. 02:56 skrev David Holmes <david.holmes at oracle.com>:

> On 23/01/2013 10:12 PM, Erik Joelsson wrote:
>> On 2013-01-23 12:54, David Holmes wrote:
>>> On 23/01/2013 8:58 PM, Erik Joelsson wrote:
>>>> On 2013-01-23 11:30, Weijun Wang wrote:
>>>>> I thought building an OpenJDK or Oracle JDK can be fully controlled by
>>>>> using the --enable-openjdk-only configure option, but it seems the
>>>>> OPENJDK env variable still plays a part. If the variable is set to
>>>>> true and --enable-openjdk-only is not provided, the new build process
>>>>> gets confused and fails.
>>> 
>>> Can you point us at a log? I'd like to see exactly where the confusion
>>> arises.
>>> 
>>>>> I understand this is my fault and I should not have that variable
>>>>> around. However, it will be nice if the build can deny all external
>>>>> variables like it did with all those ALT_*** variables. Are there any
>>>>> other variables I should be aware of?
>>>>> 
>>>> This is bad, I agree. We initially kept the same variable for
>>>> controlling if the build was OpenJDK only or not as the old build,
>>>> because it made it easier during the conversion. The problem with this
>>>> variable is that it is either set or not, which makes it harder to
>>>> override in makefiles. The proper solution would be to replace this in
>>>> the new build with something like OPENJDK_ONLY=true/false and completely
>>>> ignore the old OPENJDK.
>>> 
>>> Not sure why the set/unset situation is a problem. If OPENJDK is set
>>> then it must be set to true else the sanity checks fail.
>>> 
>>> But we should locate anywhere that the make files still examine the
>>> environment for such variables - not that I thought there were such
>>> places. The environment variables should only be used to influence how
>>> configure runs, and the variables it sets should then be used by the
>>> make files.
>>> 
>> The problem I can imagine is this: Configure creates a configuration
>> without --enable-openjdk-only, which results in a spec.gmk with no
>> OPENJDK=true in it. OPENJDK=true is then set in the environment, which
>> will trigger all ifdef OPENJDK in the makefiles.
> 
> Right - sorry. I was mistakenly thinking that make only looks at environment variables if asked via -e.
> 
> This was not a problem in the old build as the makefiles were responsible for setting up all the "environment", but now if --enable-openjdk-only influences the setting of other variables, then as you say we get a hybrid effect. :(
> 
>> This would end up being
>> a hybrid between fully open and a closed build since configure has
>> already done things differently at configure time, but the makefiles
>> will try to behave as if it was an open build. I don't know where this
>> fails, but I'm not surprised that it does, and even if it didn't fail,
>> the resulting bits would be bad. If instead spec.gmk would have a line
>> like OPENJDK_ONLY=false, this would always override any environment
>> variable.
> 
> Maybe we can at least detect this by setting OPENJDK_ONLY=true for --enable-openjdk-only and then doing in spec.gmk:
> 
> ifeq ($(OPENJDK_ONLY), false)
>  ifeq ($(OPENJDK), true)
>    error This is not an OPENJDK configuration. Ensure OPENJDK is not set in your environmemt
>  fi
> fi
> 
> David
> 
> 
>> /Erik