Is there any documentation of the build architecture, in terms of
what needs to be built first, and how those build products are then
used to build the rest of the system?
Sorry if these are FAQ-type questions, I'm still trying to figure out
how this all works.
Is the requirement for an existing JDK an architectural requirement,
or is that just how the dependencies of the build system have evolved
over time?
*Could* the build system be designed in such a way that the early
generated native tools can be built completely from native sources,
which are then used to start building the Java portions? I can see
the benefits/pitfalls of the two different philosophies.
1. Assume an existing JDK, which is used early in the process. This
allows the build process to leverage existing Java tools and
libraries (from an earlier version of the JDK) and could make it
easier to develop cross-platform build processes, as well as easier
to port new versions of the JDK to existing JDK platforms.
2. Assume no existing JDK, build the smallest native kernel required,
then through a combination of further native compilation and javac
compilation, bootstrap itself to the point where it can then build
the rest of the JDK.
Point 2 is probably harder to engineer, but would make it easier to
port to new platforms. Point 1 would make the build process for new
versions of OpenJDK simpler to implement in a cross platform way, but
would make porting to brand new platforms very difficult. Actually,
you'd have to have some special build process for bootstrapping to a
new platform. But this is basically the situation you have right now,
isn't it?
Also, would it be correct to think about this build process as having
exactly two types of build trees - a native portion (built with
native compiler tools) and a Java portion, built with javac and JDK
tools, that have been built from the native step?
On the native part, I'll just assume the status quo make files and
such are the best way of handling this. But for all the Java tasks
and packaging and Java code generation, wouldn't an all-Java build
process be simpler to implement and maintain? I don't have a lot of
experience with make, but it seems very archaic and inefficient. I
use Ant on a daily basis, and I'm not very enthusiastic about that
either. I don't think a declarative programming style lends itself
well to writing build systems. I think a scripting language would
make it much easier, something like Groovy perhaps.
I'm just asking these questions in the context of what would be
ideal. I understand there is a lot of work invested in the current
build system and it would not be trivial to re-implement it. But I'm
thinking of this specifically for a Mac OS X port, and how this would
fit in with the OpenJDK project, and whether it would be better to
just start with a new build system for this port, that might then
evolve enough to be useful for the general OpenJDK case.
Again, just high-level pie-in-the-sky thinking for the moment.
Rob Ross, Lead Software Engineer
E! Networks
---------------------------------------------------
"Beware of he who would deny you access to information, for in his
heart he dreams himself your master." -- Commissioner Pravin Lal
On Jun 3, 2008, at 11:56 AM, Kelly O'Hair wrote:
Java (BOOTJDK) is and will always be a requirement to build the JDK,
can't see that ever going away.
Many build tools are already written in Java (see jdk/make/tools)
so I don't see how changing sh scripts to Java changes the build
dependencies.
As far as Ant goes, I have mixed feelings about it. But I'm becoming
convinced that it has some big benefits when building Java code, and
integrates better with the various IDEs.
Just so I understand the issues, exactly how has the shift to Ant made
the build more tricky for you?
-kto
Andrew John Hughes wrote:
2008/6/3 Kelly O'Hair <[EMAIL PROTECTED]>:
As far as I know, only Ubuntu (and only 8.04?) depends on bash.
No other OS seems to have a problem using plain old antique sh.
---
Ideally, these sh scripts used in the build process should be
changed
to be something else, maybe small Java apps. Someday.
-kto
The shift to using Ant already made the build more tricky IMO.
Relying on Java for building Java even more just seems prone to
problems,
especially when it comes to bootstrapping.
