You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2005/11/21 13:17:16 UTC
Building choices (was: Re: Code contribution to harmony)
Andrey Chernyshev wrote:
> On 11/15/05, Tim Ellison <t....@gmail.com> wrote:
>
>>In the end we decided to go with a 'conventional' native code tool set
>>for the native source, and 'conventional' Java code tools for the Java
>>source. People just felt more comfortable with that.
>>
>>Do you think we are missing out on something ;-) ?
>
>
> Well, I can see a few potential issues with such "mixed" approach:
> - In order to contribute, people would have to learn both building
> technologies - Ant and make, someone may give up.
I don't see a great advantage to asking people to learn 'cpptask' rather
than 'make'. I would suggest that many more C programmers are familiar
with 'make' already, so we are not asking them to learn something new.
However, the Ant cpptask wrappers the same platform compiler, so the
complexity in terms of options etc. is equivalent. The resource
dependency checking performed by Ant and make are both done 'behind the
scenes' anyway. Was there some other part of Ant and make that you were
thinking about?
> - Having make in addition to ant will introduce additional
> dependencies for the build. While make is available on Unix systems,
> it is not available on Windows by default, one would have to install
> it as a part of cygwin, MSVC or whatever.
You are right, there is no C development environment shipped with
Windows by default. I doubt we can fix that very easily :-) Everyone
will need to install a C development environment to use cpptask too.
> Another issue is that nmake
> that comes with MSVC and gmake are not compatible with each other.
Agreed. One of the many platform-specific areas we deal with everyday.
At development time the differences include code and resource
compilers, packaging and so on; at runtime the differences include
resource management, OS APIs, etc.
I see that in HARMONY-16 you have used break-out XML files (jaaswin.xml
and jaasnix.xml) to deal with the build-time differences. That's fine.
Some level of the tooling will have to bridge the differences.
> - Overall, ant possibly better suites the portability needs, at least
> between Windows and Linux
There is a distinction to be drawn between the portability of the
'product' (i.e. the VM, class libaries, tools, etc.) that we are
building, and the portability of the toolsuite that is used to build it.
I'm not convinced of the need to make the development toolset portable
across all platforms.
I'd rather enable people to choose their development tooling within the
broadest set of resources that we are prepared to support consistently.
So if people want to use command-line tools (emacs, make), or IDEs
(Eclipse CDT or VisualSudio) then they should be free to make that choice.
> As an example, I can suggest to look at Intel's contribution of the
> security package at http://issues.apache.org/jira/browse/HARMONY-16.
>
> Though the experts may say the example isn't ideal (the native part of
> security is really simple such that the build doesn't even utilize ant
> cpptask), it still may serve as illustration of the alternative
> approach, e.g. building a product using a single language.
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.
> Thank you,
> Andrey Chernyshev
> Intel Managed Runtime Division
>
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Building choices (was: Re: Code contribution to harmony)
Posted by Andrey Chernyshev <a....@gmail.com>.
On 11/23/05, Graeme Johnson <Gr...@ca.ibm.com> wrote:
> 'make' also simplifies the bootstrapping issue. When you are doing the
> initial port of the VM to a new platform, and you don't have java
> running yet, having your build instructions encoded in Ant is problematic.
>
Well, good point. However, as it was suggested earlier in the thread,
let's separate the building platforms and the target platforms. I
would expect that one most likely will choose some conventional
platform for the development and building. Hence, there is a high
probability that Java is already available there. Bootstraping for
"Javaless" platforms can be solved with C cross compiler. GCC does
exactly the same to bootstrap.
> Relying on the availability of a previous java port to get the Harmony
> VM building seems like a questionable porting story. 'make' of one flavor
>
> or another is pretty much universally available, and seems like the
> pragmatic choice for building C code.
I would agree that make is the preferred choice for any Unix
developers. The problem actually comes when we start to develop on
Windows (I believe, there still be a plenty of such developers). Let's
consider the specific example – I'm building on Windows. I can use
nmake, but, it is MSVC specific and is not available on Linux, hence
it can't be our choice. Next, I'll try to use gmake – this, however,
requires me to install cygwin in addition to MSVC. Note that I already
have Java installed since I'm building the java sources with ant. Then
the question comes, why do I have to install something else?
The problem is that C development toolset isn't necessarily associated
with the make toolset, and the make toolsets are not always compatible
with each other. Make-based builds sometimes tend to do not work even
between the different Linux distributions, if not specially hacked.
Java luckily conforms to a single standard, hence works everywhere
similarly, if only available.
I'm currently working on preparing a prototype of a full ant-based
build system which would allow to build the provided class libraries
contributions. Perhaps it would make sense to return to this talk some
time later if I get the prototype working.
Thank you,
Andrey Chernyshev
Intel Managed Runtime Division
Re: Building choices (was: Re: Code contribution to harmony)
Posted by Robin Garner <Ro...@anu.edu.au>.
Matt Benson wrote:
>--- Ashish Ranjan <as...@gmail.com> wrote:
>
>
>
>>that is the most convincing argument till now. :-)
>>
>>
>
>+1 from an Ant PMC member. That logic is irrefutable.
> :)
>
>-Matt
>
>
>
>
What about cross-compilation/cross-building ? If harmony is to be
successful in its goal of wide portability I would expect that the build
process would make cross-builds almost as easy as native builds.
-- Robin
>>bye :-)
>>Ashish Ranjan
>>India
>>ashishwave@yahoo.com
>>
>>On 11/23/05, Graeme Johnson
>><Gr...@ca.ibm.com> wrote:
>>
>>
>>>Tim Ellison <t....@gmail.com> wrote on
>>>
>>>
>>11/21/2005 07:17:16 AM:
>>
>>
>>>>Andrey Chernyshev wrote:
>>>>
>>>>
>>>>>On 11/15/05, Tim Ellison
>>>>>
>>>>>
>><t....@gmail.com> wrote:
>>
>>
>>>>>>In the end we decided to go with a
>>>>>>
>>>>>>
>>'conventional' native code tool set
>>
>>
>>>>>>for the native source, and 'conventional' Java
>>>>>>
>>>>>>
>>code tools for the Java
>>
>>
>>>>>>source. People just felt more comfortable
>>>>>>
>>>>>>
>>with that.
>>
>>
>>>>>>Do you think we are missing out on something
>>>>>>
>>>>>>
>>;-) ?
>>
>>
>>>>>Well, I can see a few potential issues with
>>>>>
>>>>>
>>such "mixed" approach:
>>
>>
>>>>>- In order to contribute, people would have to
>>>>>
>>>>>
>>learn both building
>>
>>
>>>>>technologies - Ant and make, someone may give
>>>>>
>>>>>
>>up.
>>
>>
>>>>I don't see a great advantage to asking people
>>>>
>>>>
>>to learn 'cpptask' rather
>>
>>
>>>>than 'make'. I would suggest that many more C
>>>>
>>>>
>>programmers are familiar
>>
>>
>>>>with 'make' already, so we are not asking them
>>>>
>>>>
>>to learn something new.
>>
>>
>>>>[snip]
>>>>
>>>>
>>>'make' also simplifies the bootstrapping issue.
>>>
>>>
>>When you are doing the
>>
>>
>>>initial port of the VM to a new platform, and you
>>>
>>>
>>don't have java
>>
>>
>>>running yet, having your build instructions
>>>
>>>
>>encoded in Ant is problematic.
>>
>>
>>>Relying on the availability of a previous java
>>>
>>>
>>port to get the Harmony
>>
>>
>>>VM building seems like a questionable porting
>>>
>>>
>>story. 'make' of one flavor
>>
>>
>>>or another is pretty much universally available,
>>>
>>>
>>and seems like the
>>
>>
>>>pragmatic choice for building C code.
>>>
>>>Graeme Johnson
>>>J9 VM Team, IBM Canada.
>>>
>>>
>>>
>
>
>
>
>__________________________________
>Yahoo! FareChase: Search multiple travel sites in one click.
>http://farechase.yahoo.com
>
>
Re: Building choices (was: Re: Code contribution to harmony)
Posted by Matt Benson <gu...@yahoo.com>.
--- Ashish Ranjan <as...@gmail.com> wrote:
> that is the most convincing argument till now. :-)
+1 from an Ant PMC member. That logic is irrefutable.
:)
-Matt
> bye :-)
> Ashish Ranjan
> India
> ashishwave@yahoo.com
>
> On 11/23/05, Graeme Johnson
> <Gr...@ca.ibm.com> wrote:
> >
> > Tim Ellison <t....@gmail.com> wrote on
> 11/21/2005 07:17:16 AM:
> >
> > > Andrey Chernyshev wrote:
> > > > On 11/15/05, Tim Ellison
> <t....@gmail.com> wrote:
> > > >
> > > >>In the end we decided to go with a
> 'conventional' native code tool set
> > > >>for the native source, and 'conventional' Java
> code tools for the Java
> > > >>source. People just felt more comfortable
> with that.
> > > >>
> > > >>Do you think we are missing out on something
> ;-) ?
> > > >
> > > >
> > > > Well, I can see a few potential issues with
> such "mixed" approach:
> > > > - In order to contribute, people would have to
> learn both building
> > > > technologies - Ant and make, someone may give
> up.
> > >
> > > I don't see a great advantage to asking people
> to learn 'cpptask' rather
> > > than 'make'. I would suggest that many more C
> programmers are familiar
> > > with 'make' already, so we are not asking them
> to learn something new.
> > >
> > > [snip]
> >
> > 'make' also simplifies the bootstrapping issue.
> When you are doing the
> > initial port of the VM to a new platform, and you
> don't have java
> > running yet, having your build instructions
> encoded in Ant is problematic.
> >
> > Relying on the availability of a previous java
> port to get the Harmony
> > VM building seems like a questionable porting
> story. 'make' of one flavor
> >
> > or another is pretty much universally available,
> and seems like the
> > pragmatic choice for building C code.
> >
> > Graeme Johnson
> > J9 VM Team, IBM Canada.
> >
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Re: Building choices (was: Re: Code contribution to harmony)
Posted by Ashish Ranjan <as...@gmail.com>.
that is the most convincing argument till now. :-)
bye :-)
Ashish Ranjan
India
ashishwave@yahoo.com
On 11/23/05, Graeme Johnson <Gr...@ca.ibm.com> wrote:
>
> Tim Ellison <t....@gmail.com> wrote on 11/21/2005 07:17:16 AM:
>
> > Andrey Chernyshev wrote:
> > > On 11/15/05, Tim Ellison <t....@gmail.com> wrote:
> > >
> > >>In the end we decided to go with a 'conventional' native code tool set
> > >>for the native source, and 'conventional' Java code tools for the Java
> > >>source. People just felt more comfortable with that.
> > >>
> > >>Do you think we are missing out on something ;-) ?
> > >
> > >
> > > Well, I can see a few potential issues with such "mixed" approach:
> > > - In order to contribute, people would have to learn both building
> > > technologies - Ant and make, someone may give up.
> >
> > I don't see a great advantage to asking people to learn 'cpptask' rather
> > than 'make'. I would suggest that many more C programmers are familiar
> > with 'make' already, so we are not asking them to learn something new.
> >
> > [snip]
>
> 'make' also simplifies the bootstrapping issue. When you are doing the
> initial port of the VM to a new platform, and you don't have java
> running yet, having your build instructions encoded in Ant is problematic.
>
> Relying on the availability of a previous java port to get the Harmony
> VM building seems like a questionable porting story. 'make' of one flavor
>
> or another is pretty much universally available, and seems like the
> pragmatic choice for building C code.
>
> Graeme Johnson
> J9 VM Team, IBM Canada.
>
Re: Building choices (was: Re: Code contribution to harmony)
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Nov 21, 2005 at 12:17:16PM +0000, Tim Ellison wrote:
> There is a distinction to be drawn between the portability of the
> 'product' (i.e. the VM, class libaries, tools, etc.) that we are
> building, and the portability of the toolsuite that is used to build it.
Hmm.
> I'm not convinced of the need to make the development toolset portable
> across all platforms.
Regardless of the relative merits of Ant and make and other alternatives
(I tend to think both Ant and make are painful beyond a certain project
size. Lately I've been a fan of scons (http://www.scons.org/)), having a
stable, consistent, free, dependable, stable, easily accessible, stable (etc)
build system is quite important for open source project success. I didn't
say portable, but having a cross-platform (cross-make, cross-compiler, ...)
build system means you only need to maintain one which might mean all those
other factors are consistently taken care of.
The "build consistency" of higher level tools such as Maven or the various
setups for all the scripting languages (Ruby Gems comes to mind) is very
valuable and if its attainable for us (really, I don't have a clue) then
that is quite valuable.
LSD
Re: Keeping Social Dynamics in Mind [was Re: Building choices]
Posted by ac...@apache.org.
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. ;-)
>
Keeping Social Dynamics in Mind [was Re: Building choices]
Posted by Stefano Mazzocchi <st...@apache.org>.
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. ;-)
--
Stefano.
Re: Building choices (was: Re: Code contribution to harmony)
Posted by Graeme Johnson <Gr...@ca.ibm.com>.
Tim Ellison <t....@gmail.com> wrote on 11/21/2005 07:17:16 AM:
> Andrey Chernyshev wrote:
> > On 11/15/05, Tim Ellison <t....@gmail.com> wrote:
> >
> >>In the end we decided to go with a 'conventional' native code tool set
> >>for the native source, and 'conventional' Java code tools for the Java
> >>source. People just felt more comfortable with that.
> >>
> >>Do you think we are missing out on something ;-) ?
> >
> >
> > Well, I can see a few potential issues with such "mixed" approach:
> > - In order to contribute, people would have to learn both building
> > technologies - Ant and make, someone may give up.
>
> I don't see a great advantage to asking people to learn 'cpptask' rather
> than 'make'. I would suggest that many more C programmers are familiar
> with 'make' already, so we are not asking them to learn something new.
>
> [snip]
'make' also simplifies the bootstrapping issue. When you are doing the
initial port of the VM to a new platform, and you don't have java
running yet, having your build instructions encoded in Ant is problematic.
Relying on the availability of a previous java port to get the Harmony
VM building seems like a questionable porting story. 'make' of one flavor
or another is pretty much universally available, and seems like the
pragmatic choice for building C code.
Graeme Johnson
J9 VM Team, IBM Canada.