Supporting custom-spec.gmk

Jeremy Manson jeremymanson at google.com
Thu Oct 3 02:58:08 UTC 2013


Hi David,

I only sort-of understand what you are saying.  My workflow is to create a
build/ directory, run configure from the JDK directory in that build/
directory, and then run make.  I also want some custom options in my spec.

With the way it is currently set up, I would have to remember to copy the
custom-spec in by hand after I run configure.  That's awful.

Now, I could write a script to do both of these steps, but surely that's
what configure is for in the first place?

My thought was that, because you prescribe it to be a custom-spec.gmk in
the build/ directory, suggesting what it should start as is not so
terrible.  Plus, it allows you to use configuration variables, which is
nice.  It is also worth pointing out that the inclusion of my patch doesn't
actually mandate anything - if there is no custom-spec.gmk.in, then you can
create it exactly as you are creating it now.  This is just an additional
option.

OTOH, perhaps it seems too prescriptive.  Could you imagine instead having,
say, a configure command line option to tell the system where to find (and
copy in) this file?

(Please be gentle with me, as I'm an autoconf newb, and I recognize that
this might be something very, very standard that I just don't know about.)

Jeremy


On Wed, Oct 2, 2013 at 7:20 PM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Jeremy,
>
>
> On 3/10/2013 10:20 AM, Jeremy Manson wrote:
>
>> I note that the bottom of spec.gmk.in has this nugget:
>>
>> # Include the custom-spec.gmk file if it exists
>> -include $(dir @SPEC@)/custom-spec.gmk
>>
>> There is no support in the configuration file to make sure that this file
>> exists in the build directory.  Any support for something like the
>> following patch?
>>
>
> The whole point here is that there may or may not be a custom-spec.gmk
> present, but if there is then we include it. We don't mandate how that file
> gets created so the existence, or not, of a custom-spec.gmk.in doesn't
> tell you anything. Plus you also have to know where to look for the .in
> file - which need not be AUTOCONF_DIR.
>
> David
> -----
>
>
>
>> diff -r 0cc21882d2f6 common/autoconf/basics.m4
>> --- a/common/autoconf/basics.m4 Thu Sep 26 10:43:04 2013 -0700
>> +++ b/common/autoconf/basics.m4 Wed Oct 02 17:19:33 2013 -0700
>> @@ -457,6 +457,10 @@
>>   AC_CONFIG_HEADERS([$OUTPUT_**ROOT/config.h:$AUTOCONF_DIR/co**nfig.h.in<http://config.h.in>
>> ])
>>   # The spec.gmk file contains all variables for the make system.
>>   AC_CONFIG_FILES([$OUTPUT_ROOT/**spec.gmk:$AUTOCONF_DIR/spec.**gmk.in<http://spec.gmk.in>
>> ])
>> +# The custom-spec.gmk file is an optional file that contains
>> user-specific
>> config
>> +if test -e $AUTOCONF_DIR/custom-spec.gmk.**in<http://custom-spec.gmk.in>;
>> then
>> +  AC_CONFIG_FILES([$OUTPUT_ROOT/**custom-spec.gmk:$AUTOCONF_DIR/
>> custom-spec.gmk.in])
>> +fi
>>   # The hotspot-spec.gmk file contains legacy variables for the hotspot
>> make
>> system.
>>   AC_CONFIG_FILES([$OUTPUT_ROOT/**hotspot-spec.gmk:$AUTOCONF_**DIR/
>> hotspot-spec.gmk.in])
>>   # The bootcycle-spec.gmk file contains support for boot cycle builds.
>>
>>



More information about the build-dev mailing list