ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: C/C++ Compile Task - Another
Date Wed, 20 Jun 2001 10:48:09 GMT

G'day Mark,

I've had a quick look at your code.  Looks good.  I reckon we have a nice
complement of stuff here.  Just need to whack it into shape.

I suppose first up we should figure out how we want C++ support to work in
ant.  Then we can figure out how.

Looking at the differences between our 2 approaches:

Biggest difference is a single unified task vs. separate compile and link
tasks.  The more I think about a unified task, the more I like it.  After
all, it's the approach the compilers take.  It didn't even cross my mind
that you would do this as a single step.  Too long writing crappy Makefiles,
I guess :)

The only concern I have about a unified task is that we may end up with a
bloated interface for the task, with a whole bunch of attributes that have
"ignored if not linking" or "required if linking, but only if not compiling"
in their description.  But there's ways we can deal with this if it happens.

So +1 for a single task.

The name of the task is another issue.  I think the names I chose are pretty
crap - I'd like something more descriptive, <cppcomp> is fine.  Maybe
<cppcompile> or <compilecpp> is better?

We have a bunch of attributes and nested elements are very similar, but
don't quite behave the same.  Below are my thoughts on how we could address

* define/undefine.

Your support for these is way better than mine.  I don't even deal with
undefine.  Having a <defineset> data type is very nice.  Let's stick with

I'd also like to have shortcut 'define' and 'undefine' attributes, similar
to what I have, which create an implicit defineset.

* additional compiler/linker arguments.

We both use string attributes here.  Perhaps we should make these a bunch of
nested elements instead, and make them CommandLine.Argument objects - maybe
called <compilerarg> and <linkerarg>?

* include and library path

We're the same here.  I have an additional sysincludepath, which is passed
to the compiler, but not used in header file dependency checking.  The
intention was to use this to cut down the amount of work the task has to do
in parsing.  It's not really necessary.  (Just don't trust my parser, is all

I'd like to have shortcut 'libpath', 'includepath' and 'sysincludepath'
attributes as well.

* debug

The behaviour differs slightly here.  When debug is set to false in my
compile task, it switches on optimization.  It shouldn't really - I was
being lazy.  We should add an 'optimize' attribute if we want to support

* source file set

A unified C++ task should support these cases:
  - compile a set of source files, but do not link.
  - link a bunch of object files and libraries, but do not compile.
  - compile a set of source files, link in the resulting object files plus
some libraries.
  - compile a set of source files, link in the resulting object files plus
some additional object files and libraries.

So, the input files for this task are a mix of source files, object files
and library files.  And a set of library names (for libraries which need to
be searched for in the lib path).

Rather than pull these out into separate filesets for each type of file, I'd
rather we just allow one or more filesets, each with a mix of file types,
and use the file name to figure out which step to include them in.

You've used <fileset>, I've used <source>.  I'd rather not use something as
general as <fileset>, and <source> implies a set of C++ source files.  Bit
stuck on a name here.

* libraries.

Given the above, I wonder if your <libraryset> datatype is necessary?  We do
need the two different ways of referencing libraries that it provides: by
file name, and by base name.  If we allow libraries to be included in the
input file set - as above - then we're left with just a list of library base
names.  Let's make this a 'libs' attribute and keep it simple.

* intermediate dir

My compile task preserves the relative directory structure from the source
directory, under the output directory.  The plan here was that you could run
compile once, but link several times using files from different

A unified task makes this less useful, so let's just put the object files in
one directory, as your task does.

* output file name

Not entirely clear on why you have separate 'execdestdir' and 'outfile'
attributes.  Can we use a single 'outfile' attribute here?

* choosing the compiler.

You've called it 'compiler', I've called it 'suite'.  Let's use compiler.

Your task requires a compiler be specified.  I'd rather we made it optional,
and use a default compiler for the OS the task is running on.  Exactly what
the default for a particular OS should be - that's another issue.

One of my goals for the C++ support in ant is to make the task as
cross-platform as possible, so that a build writer isn't forced to use
different attribute values for each different platform the build runs on.
Requiring the build writer to specify a compiler forces this.  Granted, any
real project almost always needs platform specific properties (defines,
libs, whatever) - but let's not force this on every project.

That's about it.  There's a few other bits and pieces, but they can wait.

What do you reckon about all this?  Some feedback from ant-dev people would
be appreciated as well.

Let's get some agreement on this, then we can figure out how to get this all
done and (hopefully) committed.


> -----Original Message-----
> From: Mark A Russell []
> Sent: Wednesday, 20 June 2001 5:37 AM
> To:
> Subject: RE: C/C++ Compile Task - Another
> The biggest difficulty would be that I only have access to the AIX and SUN
> machine from work, so testing would be limited by that access.
> Though if we
> did get a complete C++ task I could definently make use of it in our
> projects on those machine. So real life use good enough for test? =)
> I do have access to both gcc and vstudio at home though so that
> won't be an
> issue.
> I would have no problem working on this with Adam, just as long
> as your not
> in a big rush because I'm carrying a very full load with a full
> time job and
> full time class schedule.
> So Adam what do ya think, shall we?  I haven't yet had a chance to look at
> your code but I should be able to sometime this evening.
> Mark R
> -----Original Message-----
> From:
> []On Behalf Of Glenn McAllister
> Sent: Tuesday, June 19, 2001 1:22 PM
> To:
> Subject: Re: C/C++ Compile Task - Another
> Mark A Russell wrote:
> > My timing is just wrong, somebody Adam Murdoch already beat me
> but here it
> > is anyway.
> It looks like Adam and you have tackled the same problem but from slightly
> different
> perspectives: you've made it easy to extend, and Adam did the dependency
> stuff, and
> you both did different compliers.
> Would the two of you be interested in working together to combine the best
> features
> of both tasks?  If we had a pretty complete c++ task set, I'm
> sure we would
> win a lot
> more converts to Ant. :-)
> Glenn McAllister

Do You Yahoo!?
Get your free address at

View raw message