Questions on using configure

[Magnus Ihse Bursie]

On 2011-10-20 13:03, David Holmes wrote:
>
> So you are saying that if configure doesn't find itself in the current 
> directory then it will assume that the current directory is the 
> directory to be used for the end build?

Yep. Or, more specifically, if the current directory is not the 
top-level directory, then it will use the directory for the build. I'm 
not sure the check for how to locate the top-level directory includes 
trying to find the configure script, but I might be wrong.

> So here is the scenario based on the way I work today. I use a script 
> to set various build variables including ALT_OUTPUTDIR. If I'm working 
> on a fix I do a build and maybe I'll call it v1 and that will be part 
> of the ALT_OUTPUTDIR setting. I then change the fix to v2 and update 
> the script so that ALT_OUTPUTDIR points to a v2 directory.
>
> 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

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

This will be equal to cd'ing to each directory in "build" and runing 
make in it, one by one.

(I don't think the current target name ("ALL") is optimal, it should 
probably be changed to something like "all-configurations" or so.)

> 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"). :-)

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

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?

/Magnus