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

List:       openjdk-build-infra-dev
Subject:    Re: OPENJDK env var not playing well with new build
From:       Magnus Ihse Bursie <magnus.ihse.bursie () oracle ! com>
Date:       2013-01-25 21:18:40
Message-ID: 6CC1198C-562A-411C-A51F-354C29D552AB () oracle ! com
[Download RAW message or body]

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@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


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