small fix for makefile for building on linux

[Jonathan Gibbons]

Dalibor Topic wrote:
> Jonathan Gibbons wrote:
>> Dalibor,
>>
>> 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 
completely.


>> Going forward, we will be focussing on the build.xml file for the 
>> compiler, in make/netbeans/compiler.
>>   
> cool.
>
> 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 
list...

>
> cheers,
> dalibor topic

-- Jon