From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-20 07:33:45
----- Original Message -----
From: "Thomas Witt" <witt_at_[hidden]>
Sent: Wednesday, June 19, 2002 2:01 PM
Subject: Re: [jamboost] Signature change with-command-file rule
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> attached is a patch that should fix the issues with option handling. It
> an on-variable instead of targets for options passing and it adds the
> neccessary quoting so that whitespace embedded in libpaths is handled
> Is it right to say that binding to the filesystem is a NoOp for targets
> don't have SEARCH or LOCATE set on them ?
I'm not sure.
Yes, that appears to be the case.
> > > On the first point I decided to have binding. It's a result of the
> >> that
> > > options are handled as targets.
> > That seems like circular reasoning. "It's OK to make them targets,
> > justify by saying there's no problem with binding because I'm calling
> > targets".
> What I wanted to say was:
> On the first point I decided to have binding. It is done automatically as
> options are handled as targets.
Sounds the same to me, but let's drop that point unless you think it's
> Anyway. I now think that binding on options should be avoided. Either the
> options are compound-options(see below) and binding does not work, or
> are targets already so they can be stuffed in sources *.
That's what I was thinking.
> > > 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.
> What I wanted to say was. They do not have SEARCH or LOCATE set on them,
> bound and unbound value should be the same.
> I am talking about options that are formed of an option string and a
> name. Think /IMPLIB:"$(<)". IIUC the option string can only be formed
> an action unless I can manually retrieve the bound value while in a rule.
You can, using GLOB.
> > I'm sure that whether it works depends where various tools are
> > etc.
> > For example, try msvc-stlport with a space in the STLPORT_ROOT path.
> > Do you have a fix for this?
> Yes, see attached patch.
If you're satisfied that this fixes all the issues we discussed, I'm
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