MILESTONE and BUILD_NUMBER with new build system

[David Holmes]

On 25/09/2012 9:43 AM, Mike Duigou wrote:
> On Sep 24 2012, at 16:25 , David Holmes wrote:
>> On 25/09/2012 6:38 AM, Henri Gomez wrote:
>>> OpenJDK reports like this :
>>>
>>> openjdk version "1.8.0-internal"
>>> OpenJDK Runtime Environment (build 1.8.0-internal-myuser_2012_09_24_15_47-b00)
>>> OpenJDK Server VM (build 24.0-b21, mixed mode)
>>>
>>> With old build system I used to set MILESTONE and BUILD_NUMBER env
>>> vars to have JDK reports like this :
>>>
>>> openjdk version "1.8.0-b56"
>>> OpenJDK Runtime Environment (build 1.8.0-b56-20120918)
>>> OpenJDK 64-Bit Server VM (build 24.0-b21, mixed mode)
>>>
>>> How did we set them now with new build system ?
>>
>> I recently raised this problem with build-infra. Presently the MILESTONE
>> and JDK_BUILD_NUMBER (note name change) are used for these but they get
>> overridden by the values in the version.numbers file. So you can either
>> put the right numbers in that file, or delete those variables from the
>> file and set them via the environment.
>>
>
> (Not addressed to David but in response to his informative comment)
>
> 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.

David
-----

> Mike
>
>>
>>> Cheers
>>
>