groan: installation

Sun Nov 3 15:11:00 GMT 2002

Jeff Sturm <jsturm@one-point.com> writes:
> > IMHO GCJ should be using ant for build management.

> Does teaching ant how to run libtool (or worse, how to maintain static
> archives and DSO's on myriad platforms) really gain anything?

Make doesn't understand DSO's, nor does ant need to. See the <apply/>
task -- that one feature alone is enough of a reason to ditch make,
even if the rest of your build.xml is just a pile of <bash/> calls.
Ant is to make as c++ is to c. You generally start out by using ant
as a "better make than make" by simply rewriting each make target as
an ant target (quite easy to do). The optional <bash/> task helps a
lot with this transition. You then gradually, incrementally improve
your build process by taking advantage of ant's more structured
approach and better filesets/dependencies.
It's sort of like how novice C++ programmers start out using C++ as C
with a few neat features, and then gradually learn stuff like OO,
templates, etc.
Tom Tromey writes:
> And, anyway, I dislike ant quite a bit.

That's quite unfortunate for gcj.
> See the `u' flag in (binutils) ar. Is ar the speed-limiting step?

At least when I do an incremental build (ie change one .cc file and
recompile), yes, the 'ar' invocation to construct libgcj.a is by far
the most time-consuming step. It also causes my machine to grind to a
halt, which is frustrating if I'm trying to do something else with a
build in the background.
 - a
-- 
"Through your rags I see your vanity" -- Socrates