small fix for makefile for building on linux
Jonathan.Gibbons at Sun.COM
Fri Jun 1 11:10:20 PDT 2007
Dalibor Topic wrote:
> Jonathan Gibbons wrote:
>> Thank you for your suggestions.
> thanks for the fast reply, Jonathan!
>> j2se/src/share/opensource/javac/Makefile is a file was used in the
>> initial Subversion release of the compiler. It is still used in the
>> source bundle available on the OpenJDK site. As such, it is placed in
>> the root directory of that bundle, which is why SRC_CLASSES is as it
>> is. We have also been working on stopping the transitive compilation
>> of the j2se source tree, and you should see those fixes soon.
> ok, looking forward to see them. I'm curious: did you chose to move
> the respective packages around to fit the build script, or did you use
> a method like the one I used for the makefile patch?
Well, truth is, the Makefile works as intended, the way it was written.
It was never intended to be executed in place; instead, it was intended
to be bundled with the javac source files, as part of the initial
compiler-only release. In the bundling process, it gets "moved" to the
correct place (the root of the bundle) so that it all works as
expected. The only reason the src/share/opensource/javac directory
continues to exist is to support that same source bundle in the form
that people have been used to, while other churn continues, hopefully
for not too much longer. Eventually, src/share/opensource will go away
>> Going forward, we will be focussing on the build.xml file for the
>> compiler, in make/netbeans/compiler.
> I'm going to autoconfiscate the compiler for my own needs, as I
> explained on my blog, so ... would you be interested in receiving a
> patch that provides a configure && make && make install build
> machinery for javac? I'll host it on a google code site, or something
> else, otherwise. I am trying to figure out where to diff from, and how
> to keep my set of build system & portability patches small wrt to the
> javac trunk.
With respect, we already have too many build systems: 4 public ones (the
main JDK Makefile, the November compiler Makefile, the November compiler
build.xml, and the new OpenJDK build.xml). In addition, I have a couple
of additional private legacy build systems for some projects that
predate the OpenJDK work. So that's more than a few too many. I would
like to get this down to one build system, and while I don't expect JDK
to move to Ant wholesale any time soon (if ever!), I think it is
reasonable to consider the compiler and related tools using (just) Ant.
As for that hairy OpenJDK build.xml file -- yes, it's hairy. It's on the
list to be rationalized/simplified/cleaned up. We've started making a
> dalibor topic
More information about the compiler-dev