Review Request: Build-infra M1

[David Holmes]

A few specific comments ...

On 23/03/2012 2:34 AM, Fredrik Öhrström wrote:
> ----- ahughes at redhat.com skrev:
>
>> What is this builddeps server?  Is it something that's worth emulating
>> elsewhere?
<snip>
> 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.

The old makefiles use NFS mounted paths by default but you can of course 
override them for your local environment - that is what the ALT_* 
variables are for. In the new build you would simply define the 
non-default paths once as part of the configure process.

Not wanting to go too OT here but I see the build-deps server as 
something to be used at most per machine rather than per developer. We 
have build servers internally that can be used by dozens of developers 
and we don't want multiple copies of toolsets. Even in the new build 
system I would expect to see the toolsets (for cross-compilation) 
installed on shared NFS mounts for use by these build servers. But at 
worse I would expect to have one installation per machine.

>> 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 firmly believe that openjdk build files should only contain 
instructions for building openjdk source code. The alt-src mechanism is 
a simple mechanism to let us override an open source file with a 
"closed" one. This mechanism is available to anyone who wants to 
customize their OpenJDK without hacking the main OpenJDK sources.

However we also have a number of build files that relate only to 
building things outside the openjdk repositories - eg the 
Release-embedded.gmk and Defs-embedded.gmk files for our SE Embedded 
product. This are in the openjdk repository for our convenience. My 
"mission" is to move all such build information out of the openjdk into 
our "closed" repositories where it belongs. I previously started an 
email thread on this:

http://mail.openjdk.java.net/pipermail/build-dev/2012-January/005383.html

Unfortunately while we have a make/closed repository in the JDK repo it 
isn't used much; and it doesn't exist at all for hotspot. So the task is 
non-trivial. I also wanted to avoid doing the work twice and so have 
been waiting/watching this build-infra work. But I'm unclear how I would 
go about this separation in the build-infra world (mainly because the 
files I mention above have yet to be converted :) ).

> Yes! That is the intent, a standard way of building that everyone recognizes.

That's a somewhat biased definition of "everyone" ;-) It's been 12 years 
since I've had to work with autoconf etc and I don't miss it. :)

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

My concern, hence my question about needing to read/understand this 
file, is what happens if it doesn't work on a system? How do we debug 
the issue? Sure we can just run autoconf to generate a new (and 
hopefully working) version, but how do we determine what needs to get 
checked back into the repo?

Cheers,
David

> //Fredrik