I just pushed the first example of a configure script

[Fredrik Öhrström]

----- David.Holmes at oracle.com skrev:

> Hi Fredrik,
> 
> Can you clarify something please regarding the division of
> responsibility 
> for configure-time versus build-time. It sounds from what you wrote
> that you 
> need to run configure one-way to prepare to do cross-compilation
> builds, and 
> another way to do local builds - is that the case?

Yes, the standard way of configuring a local build is simply:

./configure

this will setup a build for the local machine using locally
discovered build dependencies, libs, ant, compilers etc etc.
This is what most external OpenJDK developers would like to have.
A friendly tool that goes actively looking for the needed
build dependencies. 

To setup a cross compilation on the local machine to build
an openjdk that runs on the sparc/solaris platform:

./configure --host=sparc-sun-solaris2.10

This will scan the local machine for cross-compilers and
tools (instead of gcc, it will prefer sparc-sun-solaris2.10-gcc 
if it is found in the path.) You also need a sysroot
for headers and libraries. Usually the sysroot path is encoded
into the cross-compiler binaries. 

Inside Oracle we can also do:

./configure --host=sparc-sun-solaris2.10 --with-builddeps-server=ftp://ourbuilddeps.server

You can of course use the builddeps server for non-cross compile builds.
./configure --with-builddeps-server=ftp://ourbuilddeps.server
this is useful for building the OpenJDK using a standardized 
compiler and standardized headers and libraries.
These will be stored locally on your machine which means that
you can disconnect your laptop from the network and still build.

Now, another important reason for moving to configure is to move
towards capabilities detection instead of the groups Solaris/Linux/Windows.

I have been told that AIX for example, half of the time behaves like Solaris
and half of the time like Linux, which makes it very time consuming
to create a port for that operating system. If we use
ifdefs that check for particular behaviour instead of which group of OS
the intendend host is, then porting will be much much simpler!

Since capabilities testing can take a bit of time (the are often small
test programs that check what headers and libs exists and what
functions exist in the libs). It makes sense to move the testing
out from the makefiles to the configure script. To avoid retesting
at every make invocation.

//Fredrik