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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-20 07:33:45

----- Original Message -----
From: "Thomas Witt" <witt_at_[hidden]>
To: <jamboost_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
>
>
> Dave,
>
> attached is a patch that should fix the issues with option handling. It
uses
> an on-variable instead of targets for options passing and it adds the
> neccessary quoting so that whitespace embedded in libpaths is handled
> correctly.

Sounds good!

> Is it right to say that binding to the filesystem is a NoOp for targets
that
> 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
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".
>
> What I wanted to say was:
>
> On the first point I decided to have binding. It is done automatically as
the
> options are handled as targets.

Sounds the same to me, but let's drop that point unless you think it's
important, OK?

> 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
they
> 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,
so
> bound and unbound value should be the same.

OK

> I am talking about options that are formed of an option string and a
bound
> name. Think /IMPLIB:"$(<[2])". IIUC the option string can only be formed
in
> 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
installed,
> > etc.
>
> Yep.
>
> > 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
satisfied too.

-Dave