A few specific comments ...
On 23/03/2012 2:34 AM, Fredrik Öhrström wrote:
----- ahug...@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
