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

From: Thomas Witt (witt_at_[hidden])
Date: 2002-06-19 13:01:02

-----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.

Comments on your last posting below:

On Wednesday 19 June 2002 00:48, David Abrahams wrote:
> 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.

Agreed. This makes the on-variable clearly superior.

>
> > 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
> acceptable abbreviation.

I wasn't thinking in terms of acceptable/unacceptable. It just makes it a 
little harder to understand.

> No; they should not be bound to the filesystem and they should not arise in
> the dependency graph.

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 ?

> >
> > 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.

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 *.

>
> > 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.

> > 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.
>

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.

>
> 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.

Regards

Thomas

- -- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9EMbi0ds/gS3XsBoRAhUeAJwLO11ViF+pjTpOo5gcOEIaRgWv0gCeJsd0
lHktWe8FmrDU/TUpBU34dDA=
=5xYU
-----END PGP SIGNATURE-----
 --------------Boundary-00=_QPSYTAD9IDCQDMHS0R54 Content-Type: text/x-diff;
charset="windows-1252";
name="options.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="options.patch"

? options.patch
Index: boost-base.jam
=================================RCS file: /cvsroot/boost/boost/tools/build/boost-base.jam,v
retrieving revision 1.63
diff -u -r1.63 boost-base.jam
--- boost-base.jam	18 Jun 2002 09:34:43 -0000	1.63
+++ boost-base.jam	19 Jun 2002 17:33:46 -0000
@@ -1802,12 +1802,10 @@
# Clean up after ourselves
Clean clean : $(command) ;

- NOTFILE $(options) ;
- DEPENDS $(options) $(sources) ;
+ OPTIONS on $(command) = $(options) ;
+
DEPENDS $(command) : $(sources) ;

- local contents = $(options) $(sources) ;
-
# Check whether there's anything to dump, so that we don't end up
# executing a line of the form:
#
@@ -1816,24 +1814,24 @@
# on Windows this writes "echo is on." into the command-file,
# which then breaks the link.

- if $(contents[1])
+ if $(sources[1])
{
# Handle the first target specially, so that the first source file
# will clear the command file
- command-file-dump-1st $(command) : $(contents[1]) ;
+ command-file-dump-1st $(command) : $(sources[1]) ;
} 

- if $(contents[2])
+ if $(sources[2])
{
# Then fill the rest up piecemeal
- command-file-dump-rest $(command) : $(contents[2-]) ;
+ command-file-dump-rest $(command) : $(sources[2-]) ;
}
}

# command-file-dump-1st: dump the first source path into the target
actions quietly command-file-dump-1st
{
- echo "$(>)" > "$(<)"
+ echo $(OPTIONS) "$(>)" > "$(<)"
}

# command-file-dump: dump the remaining source paths into the target
Index: msvc-tools.jam
=================================RCS file: /cvsroot/boost/boost/tools/build/msvc-tools.jam,v
retrieving revision 1.31
diff -u -r1.31 msvc-tools.jam
--- msvc-tools.jam	18 Jun 2002 09:34:43 -0000	1.31
+++ msvc-tools.jam	19 Jun 2002 17:33:46 -0000
@@ -134,7 +134,7 @@
# The libpath can easily break the commandline length limit.
# Therefore we add it to the commandfile 
# 06/16/02 thw
- with-command-file vc-Link $(<) : $(sources) $(NEEDLIBS) : /LIBPATH:"$(LIBPATH)" /LIBPATH:"$(STDLIBPATH)" "$(FINDLIBS:S=.lib)" ;
+ with-command-file vc-Link $(<) : $(sources) $(NEEDLIBS) : /LIBPATH:"\"$(LIBPATH)\"" /LIBPATH:"\"$(STDLIBPATH)\"" "\"$(FINDLIBS:S=.lib)\"" ;
}

actions together vc-Link
 --------------Boundary-00=_QPSYTAD9IDCQDMHS0R54--