ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Need Ammo in Make vs. Ant argument...
Date Sat, 09 Jun 2001 09:57:30 GMT
At 12:47 AM 6/9/01 -0400, David Jencks wrote:
>On 2001.06.08 21:03:40 -0400 Peter Donald wrote:
>> At 12:22 PM 6/8/01 -0500, Lance Hankins wrote:
>> >* Ant has a lot of built in support for Java and J2EE based builds, how
>> effective is it at building C++ based stuff (particularly with large
>> based systems).   We have a very heterogeneous environment here (C++
>> systems, CORBA/C++ systems, CORBA/Java systems, J2EE based systems, etc).
>> Ant *could* be made to work with native systems (ie write java tasks to
>> wrap compilers etc) however it currently is not well suited to this task.
>> I
>> wouldn't recomend it (unless you were willing to write the tasks). I
>> would
>> maybe use a mixed approach with make for native generation, compiles and
>> linking but use ant for the j2ee/java specific stuff.
>I've seen frequently "ant is no good for c++", and I wonder why.  I had no
>trouble writing a (linux/gcc) c++ compilation for an admittedly not
>enormous (about 80-90 files) project using apply for cpp > o and execon for
>linking.  It doesn't have the extensive lists of dependencies sometimes
>found in make files, but then javac doesn't have that kind of dependency
>checking either.  So just why is make better?

Essentially as it has all support tasks written for it. To do a native (ie
c/c++) you essentially have to write 3 tasks. 

* One task to generate dependency information (though in many cases this
should be integrated into next task).

* One cc/gcc task that takes a list of files. Uses dependency tree for them
(based on includes/header files etc) and then uses that to compile files
that need to be compiled (based on timestamp + dependency tree). 

* A linker. Either something like libtool that makes static/dynamic
libraries or something that makes executable.

Native cases are not as clearly defined as Java compilation and there are
many many many more options in build process. Trying to fit them all in
facade would be an extremely difficult task. Hence why no one has done it
yet ;)



| "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               |

View raw message