ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark A Russell" <mark_russ...@csgsystems.com>
Subject RE: proposed C++ support
Date Mon, 25 Jun 2001 15:27:37 GMT
The reason we decided to do it this way was to provide the most flexability.
Any developer who wishes to can use the single task OR he can use the CC
task to do just the compile, and then use the cclink task to do the link
part.

I see no reason that we can't make the cache dir configurable.

Mark A Russell
NextGen Software Engineer
CSG Systems, Inc.
E-Mail: mark_russell@csgsystems.com


-----Original Message-----
From: Peter Donald [mailto:donaldp@apache.org]
Sent: Monday, June 25, 2001 4:35 AM
To: ant-dev@jakarta.apache.org
Subject: Re: proposed C++ support


Hi,

On Mon, 25 Jun 2001 17:52, Adam Murdoch wrote:
> Last week, a couple of tasks were submitted to ant-dev, for adding C/C++
> support to ant.  One proposal was from Mark Russell, another from myself.
>
> After a bit of discussion and some helpful suggestions from various
ant-dev
> people, we've combined what we feel are the best features from both
> proposals into a single proposal.

Excellent!

> The main task is called <cc>.  It compiles and links a set of C/C++ source
> files into an executable, a shared library (DLL), or a static library.  It
> takes care of things like header-file dependencies, and platform-specific
> naming coventions.

I am not sure I like the idea of combining these two stages. There is a
couple of reasons, mainly as it is different from standard use case and it
is
different from javac style support. I just browsed through all my own
personal native code packages and they all do compilation and "linking" in
separate sweeps.

Also doing it in one task is different from how javac works. For instance,
javac just does compilation. Aggregation of all the .class files into
different output archives (ie jar/zip/ear/war etc) is done via a separate
task. Considering that executable, static and dynamic libraries are just
archives of object code (anyone remember the pain of the ar tool? ;-]) I
don't think we should break this pattern. It could also lead to task
becoming
quite large.

Also would it be possible to make the cache directory for dependency
information configurable.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message