From: Thomas Witt (witt_at_[hidden])
Date: 2002-06-19 13:01:02
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> > 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
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
> > parameters for the with-command-file rule do not have bound values.
> No, they ALL have bound values, since $(<) and $(>) are always bound in
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:"$(<)". 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,
> For example, try msvc-stlport with a space in the STLPORT_ROOT path.
> Do you have a fix for this?
Yes, see attached patch.
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
--------------Boundary-00=_QPSYTAD9IDCQDMHS0R54 Content-Type: text/x-diff;
Content-Disposition: attachment; filename="options.patch"
=================================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)
+ if $(sources)
# Handle the first target specially, so that the first source file
# will clear the command file
- command-file-dump-1st $(command) : $(contents) ;
+ command-file-dump-1st $(command) : $(sources) ;
- if $(contents)
+ if $(sources)
# 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
=================================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
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