Review Request: Build-infra M1 (original) (raw)

Andrew Hughes ahughes at redhat.com
Fri Mar 23 19:57:34 UTC 2012


----- Original Message -----

----- ahughes at 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: BDEPSCHECKMODULE(CUPS, cups, xxx, [CUPSFOUND=yes]) If successful, the variable CUPS will now point to the CUPS directory and CUPSCFLAGS will be set correctly. The configure script uses BDEPSCHECKMODULE that is implemented in builddeps.m4 Given the example command line earlier, it will read the builddeps.conf.example which for example says: builddepcups=lib/cups139.zip builddepcupsCFLAGS=-I${depdir} Thus the builddeps will automatically download ftp://buildtools.se.oracle.com/buildtools/openjdk/lib/cups139.zip unzip and install it into /home/ohrstrom/builddeps/cups139 and have CUPSCFLAGS=-I/home/ohrstrom/builddeps/cups139 and CUPS=/home/ohrstrom/builddeps/cups139 These variables are then ACSUBST 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



More information about the build-dev mailing list