Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor
 denied by domain of t.p.ellison@gmail.com)
Message-ID: <4381BACC.5090305@gmail.com>
Date: Mon, 21 Nov 2005 12:17:16 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Building choices (was: Re: Code contribution to harmony)
References: <6928c5160511150432o11a75538sc0693f395b284da2@mail.gmail.com>
	 <4379DFCF.9070001@gmail.com>
 <6928c5160511210211t117b832fl67b337cb9e534dc9@mail.gmail.com>
In-Reply-To: <6928c5160511210211t117b832fl67b337cb9e534dc9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Andrey Chernyshev wrote:
> On 11/15/05, Tim Ellison <t.p.ellison@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.