Re: fop rule broken?

From: David Abrahams (dave_at_[hidden])
Date: 2005-01-01 02:22:45

[Although this went to boost-documentation I'm dropping it from the
followup-to: list. Most of this message is concerned with Boost.Build
issues]

Eric Niebler wrote:
> 
> David Abrahams wrote:
>> 
>> Did you set your command to fop.bat or fop.sh? This looks like a
>> failure to recognize windows paths.
>> 
> 
> 
> fop.bat from the NT command prompt, fop.sh from bash under cygwin, which 
> seems like the Right Thing. (I have two different user-config.jam files 
> -- one for native Win32 builds and one for cygwin builds. I'm not sure 
> if that's necessary.)

Okay, I will fix these problems. The first and biggest problem is that
exported-ness has been ill-considered in BBv2. If you look at
common.path-variable-setting-command you can see that it has an
"exported" option that takes effect only for Unix, and that this command
is not used anywhere without the exported option ... except here:

# testing.jam
...
if [ modules.peek : NT ]
{
PATH_SETUP on $(target) =
[ common.path-variable-setting-command PATH : $(dll-paths)
%PATH% ] ;
}
else
{
PATH_SETUP on $(target) =
[ common.path-variable-setting-command LD_LIBRARY_PATH :
$(dll-paths) $LD_LIBRARY_PATH : exported ] ;
}

Of course it's only not being used in NT branch where it couldn't make a
difference anyway. This is silly code. It should look something more like

PATH_SETUP on $(target) =
[ common.prepend-path-variable-command
[ os.library-path-variable ] $(dll-paths) ] ] ;

I'll make the neccessary changes.

Finally, I agree with you about fop.bat vs. fop.sh. On the other hand,
because fop.sh is so-named, there's a configuration problem.

my user-config ought to say:

using fop : c:/tools/fop-0.20.4/fop
: c:/WINDOWS/system32/java
;

But that will only work for Windows. I could change it to:

using fop : "sh c:/tools/fop-0.20.4/fop.sh"
: c:/WINDOWS/system32/java
;

But fop.jam (and I think many other toolsets) aren't really set up to
deal with arbitrary invocation commands being passed -- for example, the
MSVC toolset expects to be able to chop off the executable name and use
the rest of the path to invoke vcvars32.bat -- although that isn't made
clear by the BBv2 documentation.

The user shouldn't have to use a test on os.name when she has a single
fop installation that will work on Windows and Cygwin. The fop toolset
could just ignore the final path element and use "fop.bat" or "fop.sh"
as appropriate, but that would prevent the user from doing some valuable
types of customization, e.g.:

using fop : c:/tools/fop-0.20.4/my-fop.bat ;

This is a more serious problem with the principle that toolsets are
initialized with a command. We have to discuss this issue.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com