No disrespect stefano, but I have a much dumber way to frame this:
automake is just easer for C/C++ code than Ant
make is just faster for C/C++ code than Ant (not by much granted)
ant is just easier/faster/better for Java code than make/automake
Thus I propose the "third way":
1. Master ant build which kicks off Automake/make for C/C++ parts
(optional to use of course)
2. Automake/make for C/C++
3. Ant stuff for Java stuff.
Of course, I have a do-ocratic bias for this. Let those who are writing
it do what makes sense and if it is a pain to build, then something is
wrong....but thats my bias.
-andy
Stefano Mazzocchi wrote:
Tim Ellison wrote:
[snip discussion on make vs ant]
I think the discussion is simply at what point the Ant script does a
platform-specific <exec>. When using 'make' the script calls-out early
and uses make to manage the native code side dependencies; when using
'cpptask' the script calls-out later and uses Ant to manage the
dependencies. We figured that 'make' was a more universal C build
system than cpptask.
Before this turns into a coloring my bikeshed argument, let me point out
one thing: how the choice of tools impacts community dynamics.
One of the goals of any project that wants to be successful is to
attract diversity in the community interested in it.
for "diversity" in apache we mean "from different affiliations, walks of
life, technical backgrounds, interests, needs, etc..". We believe
diversity in the social ecosystem plays a key role in both stability and
adaptation of the software to environmental needs. This is really the
'secret sauce' of the ASF.
At the same time, our experience teaches that there are gaps that people
are unlikely to bridge, unless helped. In short, sometimes those who are
promoting diversity and are in need for help and for sharing development
costs, have to wash the dishes first.
One argument that comes to mind to attract people is simplicity: of use,
of installation, of configuration, of understanding, of modularization,
of adapting it to ones needs, etc..
That is *not* the right way to spin it, because it wouldn't explain how
stuff like the linux kernel can manage to attract so many people to work
on it.
It's not the investment that needs to be reduced, but it's the "return"
on that investment that needs to be increased. Really, how much the
investment is practically meaningless: there *is* somebody out there
willing to do pretty much anything (in terms of energy/time/programming)
if he can do what he wants.
Now, for harmony what he wants is *crystal clear*: run java in a way
that is not possible before. Faster on a Mac, shipped with Debian,
workign on FreeBSD, working on their embedded device, avoid the "OMG,
microsoft bought sun and killed java" syndrome, you name it.
Do you *seriously* think that such a person would be stopped by having
to use make and ant?
In short, ask yourself: how likely is it to be able to attract the kind
of people that could be interested in Harmony if I make this choice? ant
vs. make, which one would be more palatable, attractive, maximize their
ROI?
And then, yes, you have to wash the dishes for a while and drag
somebody's feets because somebody in your team is unhappy about the
choice. Such is life: the day the unhappy guy in the team sees a patch
coming out of nowhere for a problem he was not able to identify, he'll
understand why he had to wash dishes for a while. ;-)
