----- Original Message -----
> ----- 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.
Ok, so it's just fetching binaries from somewhere, whereas we'd use
system installs.
>
> > 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.
>
I know that's the current status quo. It seemed to be being suggested
that the closed rules be removed from the public Makefiles and kept
separately. Maybe I misunderstood.
> > 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.
Oh yes, I'm aware there are pros and cons on both sides, and you're in
good company with gcc which also keeps configure in-tree. You have to
weigh the pain of developers updating configure with the availability
of autoconf on the build machine, and as OpenJDK builds on platforms where
it isn't readily available (Solaris, Windows, Mac OS), I can see why
there would be a preference for keeping configure in-tree.
IcedTea originally had configure in-tree, and we removed it because updates
were causing such pain. It really depends how many build changes you expect.
With IcedTea, most of the changes are build changes for obvious reasons,
so nearly every commit was regenerating configure :-)
>
> //Fredrik
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
