ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Wood <kw...@i2.com>
Subject Re: C++ tasks
Date Fri, 12 Oct 2001 14:16:14 GMT
Well, we've had an Imake based system
in place for years for C++ systems.

Then we started using Ant for java based
systems. But for systems that have a mix of java and C++,
we integrated Ant to our Imake rules. Now,
the Imake system can build C++ code as it
always did, and invoke Ant to build java.

I agree with the concept that we should keep
Ant focused on its original mission - java code.
I see no reason to burden Ant with C++ building
when perfectly good tools exist for doing that.
I think it's better to wisely use a set of tools,
than to demand one tool do every thing. 

"Russell, Mark" wrote:
> 
> Just think of the case where your trying to integrate JNI C++ code with Java
> code, and you'd like to build them all with the same build system.  That is
> really the main reason (in my mind) for a c++ task for Ant
> 
> MAR
> 
> -----Original Message-----
> From: Les Hughes [mailto:leslie.hughes@rubus.com]
> Sent: Friday, October 12, 2001 04:06
> To: 'ant-dev@jakarta.apache.org'
> Subject: RE: C++ tasks
> 
> Hi,
> 
> Feel free to shoot me down in flames but doesn't VC++ have a perfectly good
> build system in nmake? And for multithreaded speeded up stuff what about
> clearmake (with ClearCase).
> 
> (Oh dear, what have I started....)
> 
> Bye,
> 
> Les
> 
> > -----Original Message-----
> > From: Curt Arnold [mailto:carnold@houston.rr.com]
> > Sent: 11 October 2001 03:50
> > To: ant-dev@jakarta.apache.org
> > Subject: Re: C++ tasks
> >
> >
> > > I'm hoping to begin work on this again soon (in the next
> > few weeks) but my
> > > intent includes a substantial rewrite of the initial task.
> > Mostly because
> > I
> > > want to speed the task up so I intend to include multithreading
> > capabilities
> > > into the task.  For now though this is still in design with coding
> > hopefully
> > > to start end of month.
> >
> > Speed is a very good thing.
> >
> > >
> > > If needed I can repost both Adam and My tasks to the list
> > or else email
> > them
> > > direct to you.
> >
> > I'd appreciate your sending them to me.
> >
> > >
> > > One word of warning is that the linker part of my task does
> > not function
> > > properly on Sun Workshop, other then that everything should
> > be working
> >
> > My primary interest is driving the Microsoft Visual C++
> > compiler on Win32.
> >
> > I'd appreciate your thoughts on compile speed minimization.
> > If compilation
> > is processor-bound and you aren't on a multiprocessor system,
> > I wouldn't
> > think that multiple threads would gain you any performance.  Though a
> > thread-per-processor would probably be appropriate.
> >
> > Definitely, I would think that you would want to minimize the
> > number of
> > processes created (that is not exec a new process for each
> > .c[pp] file) and
> > minimize the number times CL.EXE is loaded.
> >
> > Would the same optimizations be appropriate for gcc or other
> > C++ compilers,
> > other platforms?
> >
> > Any thoughts on dependency checking?
> >

Mime
View raw message