harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoli...@apache.org
Subject Re: Keeping Social Dynamics in Mind [was Re: Building choices]
Date Mon, 21 Nov 2005 17:21:19 GMT
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. ;-)
> 


Mime
View raw message