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, Yannick mailto:[EMAIL PROTECTED] 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 as AM> general as <fileset>, and <source> implies a set of C++ source files. Bit 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 [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 >> AM> _________________________________________________________ AM> Do You Yahoo!? AM> Get your free @yahoo.com address at http://mail.yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
