Re: [jamboost] Signature change with-command-file rule

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-18 17:48:01

From: "Thomas Witt" <witt_at_[hidden]>

> I have to admit I haven't thought of that option, but making them targets
> still seems to be a valid strategy to me.

In theory they could collide with real target names, and would forever be
marked NOTFILE whether they were supposed to be or not.

> One problem might be the (ab)use of
> the name target in Jam.

Then think of it as "dependency graph node". I think "target" is an
acceptable abbreviation.

> IIUC sources are targets as well,

Yes.

> source targets
> (sounds slightly paradox to me). I think it is an acceptable model to
think
> of cmdline options being sources for the cmdfile in the same way
filenames
> are sources for the cmdfile. From the cmdfiles point of view they are
exactly
> the same.

No; they should not be bound to the filesystem and they should not arise in
the dependency graph.

> > Careful, though: some options have elements that require target binding
> > through SEARCH and LOCATE.
>
> For me there are two questions here. First should there be any binding on
> options at all and second what to do about options constructed from bound
> values and some sort of decoration.
>
> On the first point I decided to have binding. It's a result of the fact
that
> options are handled as targets.

That seems like circular reasoning. "It's OK to make them targets, which I
justify by saying there's no problem with binding because I'm calling them
targets".

> I know that there is a risk of a name clash,
> but I think that is really unlikely. When using an "on" variable there is
> choice, but a decision has to be made. When looking at msvc-tools you
will
> notice that in the current state this is actually a non-issue, as all
options
> parameters for the with-command-file rule do not have bound values.

No, they ALL have bound values, since $(<) and $(>) are always bound in
actions.

> This didn't happen by chance.
>
> As for the second point, I can't think of any fix. I think unless some
> "manual" binding is possible

I'm lost. What do you mean?

> , this simply can't be done with a general
> cmdfile rule.

What can't be done?

> Given the fact that these kind of options typically do not take
> to much cmdline space this seems not to be a real problem.
>
> What was clearly an error on my side, these binding issues should have
been
> addressed in the with-command-file rule documentation.
>
> > You want to be sure not to interfere with that
> > by pasting the target elemeents to option names.
>
> See above.
>
> > I don't think the change
> > you're trying to make can be made without careful consideration, or you
may
> > well break something.
>
> Actually there is a bug in the code, but it is not binding related.
Currently
> in msvc-tools the quotes on option arguments (think /LIBPATH:"c:\bla")
are
> not preserved. As a result you can not have whitespace in there. This was
an
> oversight. The given state is still able to build boost (I checked
> msvc/metrowerks, in advance).

I'm sure that whether it works depends where various tools are installed,
etc. For example, try msvc-stlport with a space in the STLPORT_ROOT path.
Do you have a fix for this?

> > If you're not sure you know how to do it right,
>
> Hope this makes some sense

Not yet, but keep trying, please.

-Dave