MILESTONE and BUILD_NUMBER with new build system

[Mike Duigou]

On Sep 24 2012, at 18:16 , Kelly O'Hair wrote:

> 
> On Sep 24, 2012, at 5:24 PM, David Holmes wrote:
> 
>>> 
>>> Ugh. Magic files and magic environment variables. That's very disappointing. Why are we using configure again?
>>> 
>>> I really hoped that the new build-infra system would relieve us of this kind of hocus pocus. The build system should only be looking to the environment for ephemerals that have no visible effect on the resulting bits. This would include such things as build verbosity control, temp dir location, target dir, etc. (perhaps max-mem and max-cores too)
>>> 
>>> Build parameters that do have an effect on the output bits really *must* be configure parameters. The sense of version.numbers also appears to be backwards. It should be defaults with configure params overriding. User provided params should not be overridden, silently or otherwise.
>> 
>> The current situation is not build-infra's fault, they are copying (to some extent) current practice. Current practice allows, eg, RE to set things like build number and milestone when they build and that is done via environment variables. "we" use this capability all the time to control version info etc.
>> 
>> I do not agree that these things should be configure variables at all! Why should I have to re-run configure because I've done a "hg pull -u" and am now building b57 instead of b56 ?
>> 
>> Having the build/milestone in version.numbers is okay provided that they get updated on each promotion. This currently happens with hotspot version info for example. But until/if that happens version.numbers breaks your ability to set things via the environment.
>> 
>> Regardless I should always be able to override these things via the environment.
> 
> 
> I agree with David here.  There are some things that belong to configure alone, and some that do not.

No disagreement that there are some settings that belong in configure and some are better as make vars.

> I'm not sure we have been good about deciding which belong to configure and which are just make settings.

It doesn't appear that we are even enumerating them. I am worried that the new build system is going to follow the same road of being unsustainable and unmaintainable as the old build system.

> There are literally hundreds of make variables that can impact the build,

This makes me sad.

> and although I agree we should be
> minimizing that list, it will never go away completely.

And hopefully that small number is thoroughly documented.

> As to which should belong to "the configuration"
> and which remain simple make variables, that needs discussion.
> 
> If it belongs to configure, then you have to accept the fact that changing it means re-running configure.
> I'd prefer to not be running configure over and over.

What's the alternative? wrapper scripts, defs scripts, shell rc scripts, shell command history (surprisingly popular)? If there is baggage that needs to be carried around in order to produce a build what kind of container should it be maintained in? This is an important question. Developers should be able to be reasonably mobile without needing to carry around their "tomes of openjdk building cantrips".

> Perhaps we need to start by defining what we mean by "configuration" and what it includes.

Indeed and those definitions are a good start to the required documentation.

Mike