MILESTONE and BUILD_NUMBER with new build system

[Kelly O'Hair]

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.
I'm not sure we have been good about deciding which belong to configure and which are just make settings.
There are literally hundreds of make variables that can impact the build, and although I agree we should be
minimizing that list, it will never go away completely. 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.

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

-kto