Re: javac and compilerargs
Stefan Bodewig <[EMAIL PROTECTED]> writes: > On Mon, 15 Mar 2004, Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > >> Is it OK if in the Gcj class, I do something like: >> >> String[] argsToTest = getJavac().getCurrentCompilerArgs(); > > Absolutely. The command line has been tokenized by Ant already, that > is > > > > will become three array elements "--main=foo", "-o" and "bar". I did it but I'm facing other problems. I can send the patch but the whole system is not working as I expect to do. I'll send a mail here when I got some result. Thanks for your informations, time and cooperation, Cheers, -- ~/.signature not found There are 3 types of guys -- the ones who hate nerds (all nerds, that is; girls aren't let off the hook); the ones who are scared off by girls who are slightly more intelligent than average; and the guys who are also somewhat more intelligent than average, but are so shy that they can't put 2 words together when they're within 20 feet of a girl. -- Vikki Roemer on debian-curiosa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
On Mon, 15 Mar 2004, Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > Is it OK if in the Gcj class, I do something like: > > String[] argsToTest = getJavac().getCurrentCompilerArgs(); Absolutely. The command line has been tokenized by Ant already, that is will become three array elements "--main=foo", "-o" and "bar". Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
Stefan Bodewig <[EMAIL PROTECTED]> writes: > 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 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-) :-p Is it possible to know the value of when I am in the gcj class? If yes, how? ... reading the sources is a good thing to answer your own questions! ;-) (well I found your code very clear!) Is it OK if in the Gcj class, I do something like: String[] argsToTest = getJavac().getCurrentCompilerArgs(); Then I think I got to test if every String begins with -o or --main? > If I'd put it towards the end of my TODO list it would likely never > get implemented ;-) I hope I'll have the time and knowledge to do it ;-) Cheers, -- ~/.signature not found < asuffield> a workstation is anything you can stick on somebodies desk and con them into using -- in #debian-devel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
[EMAIL PROTECTED] writes:
[...]
> 089: String jikesPath = System.getProperty("jikes.class.path");
Huh! I thought it would be more complex! ;-)
Thanks ;-) (but I think it'll be plan B ;-))
--
~/.signature not found
< asuffield> a workstation is anything you can stick on somebodies desk
and con them into using
-- in #debian-devel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
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 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 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]
RE: javac and compilerargs
> > 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 ;-) Seems to be a
> good solution. Can you point me were I have to patch such a
> possibility
> or will you do that? (I'm not in a hurry at all, it's a
> possible future
> project! ;-) )
Documentation is done by the task (see manual for ).
E.g. the jikes adapter uses a magic property.
src/main/.../taskdefs/compiler/Jikes:
044: public boolean execute() throws BuildException {
078: // if the user has set JIKESPATH we should add the contents as
well
089:String jikesPath = System.getProperty("jikes.class.path");
080:if (jikesPath != null) {
081:classpath.append(new Path(project, jikesPath));
082:}
Jan
Re: javac and compilerargs
Hi Stefan, Stefan Bodewig <[EMAIL PROTECTED]> writes: > On Mon, 15 Mar 2004, Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > >> I'd like to make some changes in the >> ant-1.6.1/src/main/org/apache/tools/ant/taskdefs/compilers/Gcj.java >> task to change the behavior. I'd like ant NOT to pass the -C >> argument if a nested tag exists. > > This is hard to do in a backwards compatible way. > > Honestly, I'm not sure how big our gcj user base is and how many of > them use 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. Maybe we'll need it in a near future... we are not sure yet. > But if it is bigger than that, such a change would break their builds. Isn't possible in the Gcj class to know if there is a nested tag and look at the arguments of this tag? > 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. > 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 ;-) Seems to be a good solution. Can you point me were I have to patch such a possibility or will you do that? (I'm not in a hurry at all, it's a possible future project! ;-) ) Many thanks for your time and help, -- ~/.signature not found Packages should build-depend on what they should build-depend. -- Santiago Vila on debian-devel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac and compilerargs
On Mon, 15 Mar 2004, Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > I'd like to make some changes in the > ant-1.6.1/src/main/org/apache/tools/ant/taskdefs/compilers/Gcj.java > task to change the behavior. I'd like ant NOT to pass the -C > argument if a nested tag exists. This is hard to do in a backwards compatible way. Honestly, I'm not sure how big our gcj user base is and how many of them use to pass additional arguments, the answer could very well be zero. But if it is bigger than that, such a change would break their builds. 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=. 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. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
javac and compilerargs
Hi all!
My name is Arnaud Vandyck and I'm new here. I use ant for a long time
and cannot do anything without it! ;-)
I'm also a Debian Developer (like Stefan Gybas, Takashi Okamoto and
others).
I'd like to make some changes in the
ant-1.6.1/src/main/org/apache/tools/ant/taskdefs/compilers/Gcj.java task
to change the behavior. I'd like ant NOT to pass the -C argument if a
nested tag exists.
The reason:
I'd like to be able to build java sources to native code with gcj. I
think this can be achieved if I pass some extra arguments to the
compilerarg commandline like this:
But in the Gcj task, the '-C' argument is passed
/**
* gcj should be set for generate class.
*/
cmd.createArgument().setValue("-C");
I'd like to know if I can add a condition around this line so if there
is tag, with the '-o' or '--main=' argument, no -C
argument is passed to gcj.
Many thanks for your time and help,
--
~/.signature not found
This is Unix we're talking about, remember. It's not supposed to be
nice for the applications programmer.
-- Matthew Danish on debian-devel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
