Menu
▾
▴
gobo-eiffel-develop
|
From: Sven E. <sve...@we...> - 2001-10-22 10:31:43
|
er...@go... schrieb am 22.10.01: > Andreas Leitner wrote: > > > > I am cool with --define, I was just afraid that compile_* would be the > > _only_ way for passing options to geant. > > I'm not sure whether Sven already implemented the > command-line option --define, but I'm pretty sure > that it's on his TODO list somewhere because if > I remember correctly there is already support for > command-line defined variables in geant source code. geant supports this on the commandline using the -D option: geant -Dparam1=value1 -Dparam2=value2 ... (Yes, I know I have to work on the documentation) I could change this of course if most of you would prefer the --define syntax. Just let me know. - Sven _______________________________________________________________________ 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de |
|
From: Andreas L. <no...@sb...> - 2001-10-22 10:53:20
|
On Mon, 2001-10-22 at 12:31, Sven Ehrke wrote: > er...@go... schrieb am 22.10.01: > > Andreas Leitner wrote: > > > > > > I am cool with --define, I was just afraid that compile_* would be the > > > _only_ way for passing options to geant. > > > > I'm not sure whether Sven already implemented the > > command-line option --define, but I'm pretty sure > > that it's on his TODO list somewhere because if > > I remember correctly there is already support for > > command-line defined variables in geant source code. > > geant supports this on the commandline using the -D option: > > geant -Dparam1=value1 -Dparam2=value2 ... > > (Yes, I know I have to work on the documentation) > > I could change this of course if most of you would prefer the --define syntax. > Just let me know. I'd vote for --define="param1=val1 param2=val2", because this syntax obeys the GNU command line conventions. And thus integrates well with the majority of the other tools available as free software. Andreas |
|
From: Eric B. <er...@go...> - 2001-10-22 11:10:58
|
Sven Ehrke wrote: > > I could change this of course if most of you would prefer the --define syntax. > Just let me know. Can't they both be supported: long or short option name? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Andreas L. <no...@sb...> - 2001-10-22 11:33:32
|
On Mon, 2001-10-22 at 11:09, Eric Bezault wrote: > Sven Ehrke wrote: > > > > I could change this of course if most of you would prefer the --define syntax. > > Just let me know. > > Can't they both be supported: long or short option name? Yep, short options are also allowed. But for short options the '=' is disallowed. Some apps take accept the value just with a space, but personaly I think it is cleaner to allow only long options a value and let short options server for boolean flags. Dunno what the specs say here exactly. IMO should every short option have a long option pendant, if only for self documentation purposes. Whereas long options need not have short option pendants. If I see a usage listing like: -v, --verbose ... some explanation I don't even need to look at the right hand for an explanation. The long option tells me all I need, plus it tells me what shorthand I can use. If I only see '-v' without the explanation, I could only guess what it means (version, verbose, volatile, ... :) Andreas |
|
From: Eric B. <er...@go...> - 2001-10-22 21:36:05
|
Andreas Leitner wrote: > > Yep, short options are also allowed. But for short options the '=' is > disallowed. Some apps take accept the value just with a space, But here '=' is not meant to separate the option from its value, but is equivalent to the second '=' in: --define="name=value" (whose double quote characters will be removed by the underlying shell before being passed to the application if I remember correctly). Moreover isn't the -D option the way C compilers define preprocessor values? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Andreas L. <no...@sb...> - 2001-10-22 21:51:43
|
On Mon, 2001-10-22 at 23:33, Eric Bezault wrote: > Andreas Leitner wrote: > > > > Yep, short options are also allowed. But for short options the '=' is > > disallowed. Some apps take accept the value just with a space, > > But here '=' is not meant to separate the option from its value, > but is equivalent to the second '=' in: > > --define="name=value" > > (whose double quote characters will be removed by the > underlying shell before being passed to the application > if I remember correctly). That is correct, indeed. That actuall string received by the app would be --define=name=value > Moreover isn't the -D option the way C compilers define > preprocessor values? Correct again. But to me the -Dvar=val looks a little awked. Since the value part is variable (Dvar), it is for example not parsable via optimus. But then again, --define=name=value is awked too. Hmmm, dunno. Andreas |
|
From: Andreas L. <no...@sb...> - 2001-10-22 23:40:24
|
On Mon, 2001-10-22 at 23:33, Eric Bezault wrote: > Andreas Leitner wrote: > > > > Yep, short options are also allowed. But for short options the '=' is > > disallowed. Some apps take accept the value just with a space, > > But here '=' is not meant to separate the option from its value, > but is equivalent to the second '=' in: > > --define="name=value" > > (whose double quote characters will be removed by the > underlying shell before being passed to the application > if I remember correctly). > > Moreover isn't the -D option the way C compilers define > preprocessor values? Ok, given that -D is the more correct way to go, I'll change gexace to to use that instead of --define. Sven, how should the geant interface look like then? <gexace dvar1="val1" dvar2="var2" /> Andreas |
|
From: Eric B. <er...@go...> - 2001-10-22 23:48:58
|
Andreas Leitner wrote: > > Ok, given that -D is the more correct way to go, I'll change gexace to > to use that instead of --define. But can't we support both syntax? That's what I already suggested for 'geant'. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Andreas L. <no...@sb...> - 2001-10-23 00:11:04
|
On Mon, 2001-10-22 at 23:44, Eric Bezault wrote:
> Andreas Leitner wrote:
> >
> > Ok, given that -D is the more correct way to go, I'll change gexace to
> > to use that instead of --define.
>
> But can't we support both syntax? That's what I already
> suggested for 'geant'.
Sure, thats also possible.
Btw, how can i pass options from geant to gexace currently?
I know I can nest <define> elements in <gexace> elements, but how can I
make them conditional?
The following works:
<gexace command="build" command_options="ise">
<define name="foo1" value="bar1"/>
<define name="foo2" value="bar2"/>
<define name="foo3" value="bar3"/>
</gexace>
but I need some way to only define a gexace variable if the geant
variable has also been defined:
<gexace command="build" command_options="ise">
<define name="foo1" value="${FOO1}" if="${FOO1}"/>
<define name="foo2" value="${FOO2}" if="${FOO2}"/>
<define name="foo3" value="${FOO3}" if="${FOO3}"/>
</gexace>
or some other way to archive a similar effect without needing to write
2^n tasks for n options.
tia,
Andreas
|
Thanks for helping keep SourceForge clean.
X