Hello,
Fredrik already answered most of this but I will add my own comments.
On 2012-03-22 07:15, David Holmes wrote:
Hi Erik,
My major concern with the transition here is being able to take
existing knowledge of the build system and be able to figure out where
in the new system certain things are handled. How can I tell if a
Makefile is part of the old build or the new build? Are some both?
We have created a new directory in each repository called "makefiles"
and that's where the new makefiles are. In the root, we needed more than
just makefiles and created "common" for all of the new files. It is our
intention to move the root Makefile from common/makefiles to the root
when we actually make the switch.
The jdk repo is a special case where we copied over much of the old
makefiles from jdk/make to jdk/makefiles while doing the conversion. We
needed a copy of the files to be able to change them without affecting
the old build. (Typical changes would be removing them when converted
and removing the subdirs-call to removed files and also sometimes
removing partly converted functionality.) When we are done, all of the
copied old files will be gone.
It is still unclear to me how cross-compilation is to be set up.
As Fredrik demonstrated, cross compilation has been in the design from
early on, but we haven't put effort into actually solving the embedded
build yet.
It is unclear to me how the src/closed and make/closed repositories
are supported/handled. Going forward much of what pertains to Oracle
JDK proprietary features, should be moved out of the OpenJDK
repository in my opinion.
I completely agree that we should remove all (or as much as possible)
traces of the proprietary Oracle stuff from the open makefiles. For now,
we have just used the old ifndef OPENJDK, but this is something we plan
on attacking.
Is there a cheat sheet for how to run configure? There are many
options that seems completely irrelevant to what would normally be
part of a JDK build; conversely some obvious flags seem to be missing
eg ALT_OUTPUTDIR.
We don't have such documentation yet unfortunately. It would be a great
help for us if you could give us a list of the variables that you
usually need to tinker with so that we can make sure those have options.
Is it intended that any single person actually understand the contents
of configure and need to edit it? It has strange contents (like
multiple file copyright headers in places ???).
The configure script is generated using autoconf. The main input file is
configure.ac which in turn imports a couple of more files (*.m4).
common/makefiles/compress.post
common/makefiles/compress.pre
common/makefiles/uncompress.sed
??? what is this? Is it autogenerated? How do I know if I need to add
anything to it?
These are used in an elaborate hack to work around command line length
limits. Not meant to be read by a sane human, but the resulting make
macro for outputting large amounts of parameters to a command is pretty
neat.
Does this pertain only to the new javac server or is this a general
enhancement to javac for 8?
As I understand it, javac is getting a new shiny flag (-h I think) that
will generate the headerfiles automatically for classes that either have
native methods or are annotated with the GenerateNativeHeaders annotation.
jdk, just the changes to old files
http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-other/
<http://cr.openjdk.java.net/%7Eerikj/build-infra-m1/webrev-jdk-other/>
Most of these changes seem to be related to tool changes rather than
being build system changes.
Yes, we needed to change the APIs to some of the build tools to be able
to write more effective make rules for them. If I remember correctly,
there are two kinds of changes. 1: Make the tool work from one file to
another instead of changing a file in place and 2: Change the parameter
for supplying a file containing the command line to use @file which
seems to be standard among a lot of tools. The latter was needed to make
the tools compatible with the "uncygdrive" utility.
Why do I have to cd to common/makefiles ?
As I described above, we want to keep the new build system out of the
way for now to not disrupt anything for the existing build. When we make
the switch, the common/makefiles/Makefile will move down to the root.
It's also possible to build from the outputdir if you prefer that.
I tried this today and got a javac error compiling a Java2D demo - as
report to the build-infra list.
I saw your mail and will try to figure out what's wrong. I haven't seen
this problem before.
/Erik
