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
> IIUC sources are targets as well,
> source targets
> (sounds slightly paradox to me). I think it is an acceptable model to
> of cmdline options being sources for the cmdfile in the same way
> are sources for the cmdfile. From the cmdfiles point of view they are
> 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
> 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
> 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
> notice that in the current state this is actually a non-issue, as all
> parameters for the with-command-file rule do not have bound values.
No, they ALL have bound values, since $(<) and $(>) are always bound in
> 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
> 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
> > well break something.
> Actually there is a bug in the code, but it is not binding related.
> in msvc-tools the quotes on option arguments (think /LIBPATH:"c:\bla")
> not preserved. As a result you can not have whitespace in there. This was
> 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk