From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-08-21 19:39:47
[...original post restructured a bit...]
>> Anyone got some working code implementing this transformation?
>> Also, how should Boost Build/Jam know whether to apply the transformation
>> to a specific path?
>> This can not be specified simply for 'all paths in an action' as Boost Jam
>> has now way of telling what part of an action is a 'path'.
> So the logic would have to be in individual toolsets rather than
> generic? That's a pity.
Well, actually I can not even imagine it any other way. Since actions
are nothing more than lists of commands, possibly containing some
embedded Jam variables, that get sent to an external command interpreter
(or API function directly or whatever depending on the configuration).
It does not impose any restrictions on how action content is formated or
what it contains. If some command interpreter wants them to be given in
ASCII codes spelled out in hexadecimal - that's what you need to write
there and generally Boost Jam does not care.
After all it is the individual toolsets that model specific tool use
and so it is up to them to know how to use them. They then should add
any needed configuration to allow them to work with native Windows
and/or cygwin tools.
>> We already have a :W variable modifier in Boost Jam which does this
>> conversion for a specific variable content but this works only for a cygwin
>> built Boost Jam as it uses cygwin's
>> cygwin_conv_to_posix_path()/cygwin_conv_to_win32_path() APIs.
> Can the cygwin bjam successfully call non-cygwin programs (such as
> Visual C++ and quickbook built using Visual C++)? I'm asking about
> this because it'd make building the documentation much easier if boost
> build could use both cygwin and non-cygwin programs. If this requires
> some extra configuration in user-config.jam that's fine - the
> difficulty saved would more than make up for it.
I believe it can. Depends on how the exact actions you want to
execute are written. For example, if you have:
> x = "C:\\Alibaba\\The\\Great" ;
and in your action you have:
> actions my-action
> secret-executable $(x)
> secret-executable $(x:W)
> secret-executable $(x:T)
then when that action (using the cygwin built bjam) is run you should
get the following commands executed:
> secret-executable C:\Alibaba\The\Great
> secret-executable /cygdrive/c/Alibaba/The/Great
> secret-executable C:/Alibaba/The/Great
The only difference between cygwin and non-cygwin bjam here is that
the non-bjam cygwin ignores the :W variable expansion modifier.
> Well, strictly speaking yes, but in practice you can often get away
> with just using forward slashes. For example, cygwin does enough for
> xsltproc to work with windows paths (back slashes and all) until you
> use a relative path like "../lookup.xsl". When resolving this it seems
> to assume that the separators in the base path are forward slashes, so
> it messes up the path. You can get away with a 'c:/xxx/yyy/zzz'
> because for the most part it just treats the paths as text, and cygwin
> handles the rest.
Well, if that is all you need, see if you can modify the relevant
actions to expand their variables using the :T variable expansion
modifier. That should simply cause all the back-slashes in the variable
value to be expanded as forward slashes. See the example above for an
Hope this helps.
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