Boost logo

Boost-Build :

From: Thomas Witt (witt_at_[hidden])
Date: 2002-06-18 17:28:07


Dave,

sorry for the late reply. Today I've lost a W2k server due to hardware
failure. As a result I am not going to touch the repository until I had some
sleep. That said ...

On Tuesday 18 June 2002 13:44, David Abrahams wrote:
> From: "Thomas Witt" <witt_at_[hidden]>
>
> > On Tuesday 18 June 2002 12:58, David Abrahams wrote:
> > > However, Whoa: I'm not at all sure I like the idea of making the
>
> options
>
> > > into targets, even NOTFILE targets!
> > >
> > > That really doesn't seem right to me...
> >
> > Ok, I tell you what I try to achieve, you show me the right way and I fix
>
> it.
>
> Stick the options in an "on" variable of the command-file target.

I have to admit I haven't thought of that option, but making them targets
still seems to be a valid strategy to me. One problem might be the (ab)use of
the name target in Jam. IIUC sources are targets as well, 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.

> 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. 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. 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, this simply can't be done with a general
cmdfile rule. 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).

> If you're not sure you know how to do it right,

Hope this makes some sense, otherwise I certainly don't know how to do it
right.

Thomas

-- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
 

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