ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yannick Menager <>
Subject Re[2]: C/C++ Compile Task - Another
Date Wed, 20 Jun 2001 11:14:16 GMT
Hello Adam,

why not both a single unified task and separate other tasks like
linking, with a flag to stop the main task from doing the linking if
you require fine grained control

Best regards,

Wednesday, June 20, 2001, 12:48:09 PM, you wrote:

AM> G'day Mark,

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

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

AM> Looking at the differences between our 2 approaches:

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

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

AM> So +1 for a single task.

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

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

AM> * define/undefine.

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

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

AM> * additional compiler/linker arguments.

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

AM> * include and library path

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

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

AM> * debug

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

AM> * source file set

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

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

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

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

AM> * libraries.

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

AM> * intermediate dir

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

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

AM> * output file name

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

AM> * choosing the compiler.

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

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

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

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

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

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

AM> Adam

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

AM> _________________________________________________________
AM> Do You Yahoo!?
AM> Get your free address at

Do You Yahoo!?
Get your free address at

View raw message