On Mon, 15 Mar 2004, Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > Stefan Bodewig <[EMAIL PROTECTED]> writes: > >> Honestly, I'm not sure how big our gcj user base is and how many of >> them use <compilerarg> to pass additional arguments, the answer >> could very well be zero. > > This is not a problem. I'll try to implement it myself and if the > patch is not good for you, maybe we'll apply it only in > Debian.
zero was my answer to the size of the user base I was talking about, not the chance of getting your patch into Ant 8-) >> Is there a command line argument that you'd always use when >> compiling to native code, like --main? If this was the case, we >> could silently omit -C if compiler args have been specified and one >> of them started with --main=. > > --main and maybe '-o', I don't know, but I'll ask on gcj mailing > list. If you must use --main to compile native stuff and there is no way that -C can be used together with --main, that would be a really good indicator for Ant, wouldn't it? The question only is whether the assumption holds true. The gcj list will undoubtly know. >> The only other solution I'd see would be a compiler specific magic >> property. Something like build.compiler.gcj.native and we'd drop >> -C if that property was set to true. > > No problem for me if everything is well documented ;-) I'd say the solution is second best only. Especially since you can't reset a property once it is set. This would mean that you can't have a <javac> tasl that uses -C and one that doesn't in the same build process. > Can you point me were I have to patch such a possibility Look around the src/main/org/apache/tools/ant/taskdefs/compiler directory. Jikes has some jikes specific magic properties for example. > or will you do that? If I'd put it towards the end of my TODO list it would likely never get implemented ;-) Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
