ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Pracht <>
Subject Re: Using Ant to build multitarget mixed C++/Java projects
Date Wed, 02 Jun 2004 14:46:43 GMT
I've been using Ant with multitargeted C++/Java, including JNI
stuff for about 1.5 years now.  I have mixed feelings about the 
decision, here's why:

*  Cpptasks was hard to learn because the documentation was less than 
intuitive at that time.  Also, not as many people used it then.  I've
since figured out how it works a little more, though.
*  I hate to say it, but an Ant build does run slower, especially when 
you try to as many things as I've got ant doing:  building java code, 
running an Excelsior Java to native compiler, MS VC++ compilation or GCC 
compilation, zip/tarball packaging, Installshield packaging.  I also 
think it rebuilds more than it needs.
*  A nice thing about an Ant script is that it's a little harder to make 
complicated.  The last job I had required working with a complicated 
multipart make file using two platforms.  It became very, very cryptic, 
*  Another nice thing about Ant is the filename conversion issues.  It's 
nice to be able to use UNIX file conventions on Windows or vice versa. 
Yes, there's exceptions and caveats, but it does mostly work well.  Just 
remember that the Windows *.* should be replaced with *.  I've been 
bitten by that a few times.
*  A downside to cpptasks is the releases.  I work for a large company, 
and for audit purposes, and company policy, I can't run production code 
off something in CVS.  I can't have the build instructions say, "just 
get the latest version out of CVS at ..."   I couldn't guarantee 
reproducibility.  Also, because I work for the same large company, it's 
extremely difficult to donate labor to create a later release of the 
product.  This is an issue because Cpptasks hasn't had a formal release 
in a year or two.  I'm sure they're doing great work, it's just that I 
can't take advantage of it.
*  Another downside to Cpptasks, again using the latest official 
release, is that I couldn't switch GCC compilers as easily.  There is no 
apparent way to specify a compiler version in the build.xml file.  The 
path needs to be set ahead of time.
*  Cpptasks did make porting the code a little easier.  I didn't have to 
figure out the GNU GCC options, as much.  They seemed to know which 
libraries were important.

Like other posters, I've used other make's before.  Usually they create 
hard to diagnose, and stupid errors because the make didn't like not 
having a tab, or the line continuation character wasn't the very last 
thing on the line.  They can be very hard to track down.  Ant seems to 
resolve that issue with the XML based build.  One drawback is that you 
can't nest comments within comments, which I've wanted to do about a 
hundred times, it seems.

Until recently, I had my code on one machine and did a Samba link to 
share the code.  That is, until someone pointed out that there are code 
page differences between the two machines.  My solution:  extract the 
source out of your library system to each machine.  Don't try to share 
it with Samba.  When I was sharing, I also had compilation errors 
because GCC didn't like the Windows newline character sequence, nor did 
it like the occaisional EOF marker that some people put in for some 
reason.  I can't resist saying how irritating it is that GNU refuses to 
add an option to handle these things.

You may also notice strange things regarding platform names.  On Linux, 
the OS name is something like redhat-2.4.18-04debug, for me.  On Windows 
it's Windows 2000, or something like that.  You may want to find a way 
to remove the space.  Also, the same Intel architecture is called x86 on 
Windows, and i386 on Linux.  I don't know why, but it's easy to ignore.

One downside to Ant, is that things don't work as you might expect them 
to.  For example, the tar task does not preserve permission bits, so I 
was forced to use the exec task.  It also doesn't handle symlinks very 
well.  I think these things are known, but can't be easily resolved 
because of the underlying JRE.

I would recommend Ant, Antcontrib.  However, for people whom 
reproducability is an issue, I would not recommend Cpptasks.  Yes, it 
can simplify things, but the lack of a formal release is a serious 
drawback IMHO.  I suggest using the exec/apply task for doing C and C++ 
compilation, so that you have control over how it works.

Ben Pracht

Kreinick, Michael H. wrote:

> I'm looking into various alternatives for building a set of products,
> written in a mix of C++ and Java (with some JNI). The products need to build
> under Windows, Solaris, and Linux using various compilers for each platform.
> They also need to be built with different versions of their library
> dependencies, then regression tested.
> I know Ant does have C++ build tasks. What worries me is whether Ant,
> designed with Java's build-once-run-everywhere model in mind, will work well
> to build the same source 5 or 10 different times. I've never used Ant
> before, and I haven't done as much reading as I perhaps should have, but it
> seems ill-suited to this kind of problem. I get the impression that if I
> hack hard enough I can make it happen, but that it won't be very clean
> because of the Java philosophy Ant takes for granted.
> I've looked for examples of this type of use on the Web and list with no
> luck. It seems few people are trying to use Ant for C++ at all, and none
> that I found are trying to do what I'm trying to do.
> So: Is Ant C++ support mature enough that I should even be thinking about
> using it for this? Has anyone out there tried the same kind of thing? Would
> any experienced users like to offer a sketch of how they would go about it?
> Will I be fighting the Ant project model all the way?
> I'm also looking at sCons and boost.Jam for this. If anyone has other
> suggestions, they'd be welcome.
> -Michael

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message