----- ahug...@redhat.com skrev:
> What is this builddeps server? Is it something that's worth emulating
> elsewhere?
A builddeps server is simply an ftp server with tar.gz or zip archives.
The builddeps autoconf macros are inspired by the pkg-config macros.
Lets look at this extract from configure.ac:
BDEPS_CHECK_MODULE(CUPS, cups, xxx, [CUPS_FOUND=yes])
If successful, the variable CUPS will now point to the CUPS directory
and CUPS_CFLAGS will be set correctly.
The configure script uses BDEPS_CHECK_MODULE that is implemented in builddeps.m4
Given the example command line earlier, it will read the builddeps.conf.example
which for example says:
builddep_cups=lib/cups_1_3_9.zip
builddep_cups_CFLAGS=-I${depdir}
Thus the builddeps will automatically download
ftp://buildtools.se.oracle.com/buildtools/openjdk/lib/cups_1_3_9.zip
unzip and install it into /home/ohrstrom/builddeps/cups_1_3_9
and have CUPS_CFLAGS=-I/home/ohrstrom/builddeps/cups_1_3_9
and CUPS=/home/ohrstrom/builddeps/cups_1_3_9
These variables are then AC_SUBST to end up in the spec.gmk file.
This feature to easily acquire the build dependencies is very useful
for us, since it makes it easy to have the same compiler on all
developer/build-server platforms. You can easily build the exact
same bits on your desktop, as is built on the build-farm, since
you use the exact same compiler. The old makefiles uses an nfs-mount
(/java) to store the builddeps, which unfortunately prevents
non-networked builds.
I believe that it might not be that useful to you Andrew, since the
normal package system in the Linux distribution, takes care of selecting
the compiler. It also supports automatic fetching of cross compilers
and sys-roots, so perhaps you can find a use for it.
> It's not clear to me why it's a good idea to remove traces of the
> 'closed' JDK from the makefiles. Wouldn't this only cause more divergence and
> mean that the core OpenJDK makefiles aren't being tested as much?
Not at all, we strive to have all makefiles in the open. We build entirely
based on the OpenJDK makefiles, in fact I do not think there are any closed
makefiles.
The hacks needed to insert closed code are arbitrary and visible inside the
OpenJDK
makefiles. We simply believe that a better solution can be found.
> So basically it now works like other autotools projects like gcc,
> where you run the configure in the source directory (src) from your
> build
> directory (build):
>
> $ mkdir build
> $ cd build
> $ ../src/configure
> $ make
Yes! That is the intent, a standard way of building that everyone recognizes.
> The configure script is generated using the autoconf tool and is
> pieced together by the insertion and expansion of various m4 macros. To
> change it, you alter configure.ac and then run autoconf. This was
> the focus of my last question, as having configure checked into the
> repository means that everyone has to be using the same autoconf
> to generate, to avoid superfluous changes.
I know, but the benefit of having the configure script executable
in the repo is tremendous, so the extra hassle is worth it.
In particular if you want to use builddeps to bootstrap the build
environment on for example a Solaris machine.
//Fredrik
