MILESTONE and BUILD_NUMBER with new build system

[Mike Duigou]

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.
> 
> David

(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.

Mike

> 
>> Cheers
>