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

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: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de