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 this. * 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 this. 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 optimization. * 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 subdirectories. 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. Adam > -----Original Message----- > From: Mark A Russell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 20 June 2001 5:37 AM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Glenn McAllister > Sent: Tuesday, June 19, 2001 1:22 PM > To: [EMAIL PROTECTED] > 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 @yahoo.com address at http://mail.yahoo.com
