Re: fop rule broken?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-30 14:27:12

Eric Niebler wrote:
> 
> David Abrahams wrote:
>> David Abrahams wrote:
>> 
>>>And it doesn't even work for this weird cygwin/windows hybrid situation,
>>>because guess what? The absolute paths created end up being cygwin
>>>native paths. And I promise you, the code to detect that a windows
>>>FOP/Java is being used and create absolute windows paths is even more
>>>hackish.
>> 
>> 
>> Okay, I checked in the horrible hacks that make this work. My
>> user-config.jam now contains
>> 
>> using fop : c:/tools/fop-0.20.4/fop.bat
>> : c:/WINDOWS/system32/java
>> ;
>> 
>> Enjoy it in all the poor health it has brought to the codebase ;-)
>> 
> 
> 
> You're the Boost.Build expert, but not only does this *seem* wrong to 
> me, it just doesn't work. 

'scuse me? It certainly works for me.

> When running under cygwin, you should be using 
> fop.sh, not fop.bat. 

Heh, whaddaya know, there's a fop.sh there! But will that work if my
java is not a cygwin java but a Windows java?

> Besides, with fop-0.20.5, fop.bat *can* be invoked 
> from a directory different from FOP_DIR.

Good to know. I have the previous version.

> To get this working on my machine, I had to revert your changes 

Why? What did they break?

> and 
> reapply the change to common.variable-setting-command. It seems like the 
> right fix. With this change, it works regardless of whether I run under 
> cygwin or not.

Right now the assumption seems to be that under Unix, the results of
that rule can be prepended to a command and have it affect only that
command but not any following commands. Otherwise there's no reason to
for any BB code to use the technique currently employed by the fop tool;
it could use the simpler technique of setting and exporting the variable
on separate lines. Of course, it's not a portable assumption; we don't
have a way to do the same thing under Windows. Certainly when I
implemented variable setting for BBv1 I used the technique you're
suggesting.

It surprises me that you need the change and I don't, unless perhaps
it's because you're using a Cygwin Java installation?

> I certainly wish Volodya would weigh in, though. Volodya, is there a 
> reason why common.variable-setting-command does not currently export the 
> new envar value?

I think this is a classic case of unstated assumptions in documentation
which is rampant in BBv2. We need to establish what semantics are
expected from that rule (e.g. how long is the variable setting expected
to stay in effect?) and then we can know what the fix should be.

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