Questions on using configure

[David Holmes]

On 21/10/2011 1:08 AM, Magnus Ihse Bursie wrote:
> On 2011-10-20 13:03, David Holmes wrote:
>> It sounds like with configure my script will have re-run configure in
>> the target v1 or v2 directories - is that right?
>
> Yes and no. You only have to run configure once. Then you can run make
> in the different output directories. Like this:
>
> To set up, do this once:
>
> $ mkdir -p build/build-v1
> $ mkdir -p build/build-v2
> $ cd build/build-v1
> $ ../../configure
> $ cd ../build-v2
> $ ../../configure
>
> To build just v1, do:
> $ cd build/build-v1
> $ make
>
> To build just v2, do:
> $ cd build/build-v2
> $ make

That presupposes that I know before hand that I only want v1 and v2. In 
practice what I want to do is just edit my script and change the build 
identifiers and run the script. So my script logic will now have to 
check for the existence of the output directory (based on the modified 
build identifier). If it exists then I can just (cd ...; make) but 
otherwise it will have to create it and run configure, before it can do 
the actual make.

> To build both v1 and v2, go to the top-level directory and do
> $ make ALL

I think we have another disconnect here. My top-level directory (top of 
the forest) will be on a NFS drive. My build directories will be on a 
local disk - they won't be under the top-level directory. This 
separation is critical.

>> Ok. As Andrew Hughes stated it is more normal for install to just do
>> the copying part.
>
> Which is what it does. But it needs to have something to copy first (the
> "image"). :-)

I'm pretty sure that the convention is not for install to make the thing 
to be installed. It's up to the user to run "make build install" or 
whatever.

>>> Unfortunately we have not been able to spend much time on
>>> cross-compilation yet. :( Would you be interested in helping us getting
>>> it to work?
>>
>> Sure. But we might have different expectations of how we think it
>> should work. ;-)
>
> That sounds like a good starting point for a productive discussion! What
> are your expectations of how it should work?
>
> My expectation is, basically, that I should run ./configure
> --host=<target host specification>, and get a build/<target
> host>-server-release directory with the configuration for making that
> cross compilation.

So to do a cross-compile you need to define where the cross-compiler is, 
and you need to define a bunch of cflags specific to the 
cross-compilation. How do I tell configure about those settings?

Based on

http://www.gnu.org/software/autoconf/manual/autoconf.html#Manual-Configuration

there are some assumed naming conventions for the tools, but I don't see 
how to set the actual path, nor am I confident that our tool sets will 
match these assumptions.

Further, our build is a lot more complicated than basic linux/unix 
applications that are configure based. In particular parts of the build 
create binaries to run on the end target, and parts of the build 
generate binaries to run on the build host as part of the build process. 
It is far from clear to me that a configure based build can handle that.

Also our current cross-compilation builds need additional make variables 
set - like CROSS_COMPILE_ARCH - so that the build logic knows we are 
cross compiling and can adjust other settings (like whether to do a host 
or target compilation; or whether additional/different X11 includes are 
needed).

Part of the issue may be that if we were configure based from the start 
then we would not have written our cross-compilation support the way 
that we have. It may be that what we have now is not really compatible 
with a configure based approach and would have to be changed. But I'm 
not seeing that configure brings enough to the table to justify changing 
the way we do everything.

> I know that Fredrik and I have slightly different expectations on how
> the target host specification should be interpreted. :-) There is a
> traditional way of writing host specifications in autoconf (e.g.
> i386-unknown-linux-gnu) and a traditional way that the JDK names the
> hosts (e.g. linux-i586). Unfortunately, the order of CPU vs OS is
> different, and also the name of the CPU and OS is slightly different.
>>
>>> The basic idea is that variables that affect the build are set at
>>> configure time, and not at make time. It might not have been fully
>>> implemented yet. I'm not sure about specific variables.
>>
>>
>> This concerns me. There are literally dozens of variables that affect
>> the build that I might want to tweak between builds (ie invocations of
>> make, probably with some source code modifications in between). Having
>> to re-run configure to do this seems excessive. Further I haven't seen
>> how I would tell configure about these variables. My past experience
>> with configure based builds is that configure will determine a set of
>> values for specific build variables, based on the current system and
>> the requested configuration (eg cross-compile or not) and then
>> hardwire them in to generated Makefiles. But I would not expect all
>> build variables to be handled via configure - for example I might want
>> to adjust the optimization level of a compilation of a particular file
>> and so set CFLAGS to indicate that.
>>
>> So I would expect that configure controls one set of well defined
>> properties/variables: basic things like arch, debug-level, vm variant,
>> compiler path, boot jdk. But that when invoking make you can control
>> the other build variables.
>
> This is obviously worth discussing. I don't have a real clear opinion on
> this. What does the rest of you think about this?
>
> Apart from optimization levels, what other variables do you want to
> control at make time?

Well there are the BUILD_XXX=true|false settings to control what parts 
of the JDK get built. I may want to change hotspot build settings like 
MINIMIZE_RAM_USAGE. In general our build process uses dozens of make 
variables that control both what we build and how we build it. Most of 
the "what" should be handled at the configure level, but the "how" 
should be doable at the make level in my view.

Cheers,
David

> /Magnus