I, too, would like this feature, and suggestions are welcome. There is a current solution, and it isn't the best.

The current solution is way the SubDir/SubInclude rules handle platform independent pathnames: by separating the name components with spaces. There is more support for this in jam-2.1.plus -- the as yet undocumented rules makeDirName and makeSubDir. The basic idea is that you leave the elements of the name separate for as long as possible, and then use makeDirName to turn them into a real path. For example:

makeDirName FOO : foo bar ola ;

sets $(FOO) = foo/bar/ola (on UNIX).

A solution I've contemplated (but never pursued) is to have some universal syntax usably within Jam rules (probably UNIX syntax) that gets translated to local syntax on the fly. But it's hairy on VMS, because you don't know if /a/b/c is a:[b]c or a:[b.c] (i.e. a file or a directory). Unpleasant, to say the least.

As I said, suggestions are welcome...

Christopher

| From jamm...@perforce.com Fri Aug 16 06:07:19 1996 | From: David Witten <davi...@template.com> | Subject: platform independent path names | To: jamm...@perforce.com | Errors-To: list...@perforce.com | Reply-To: JAMMING Distribution List <jamm...@perforce.com> | X-Sequence: 32 | | | I would like to be able to write file paths in jam in a way such that | it would translate into a legal path on all jam supported systems. I | would like these paths to not look too ugly, e.g., not have a $() for | every directory separator. In fact I've implemented a change in jam | that allows it. Unfortunately the change is not particularly clean, so | I am soliciting suggestions for a translatable path feature to be added | to jam. | | The reason I want this is that my company tends to have fairly deep | project directories where the layout under the root is regular. So I'd | like to be able to say: | | rootdir = /home/foo/bar # defined in an env var | | cdir = $(rootdir)/c ; | odir = $(rootdir)/o ; | | I extended jam to have two new variable modifiers, :d and :f. :d | translates the value of the modified variable from a unix style path | name to a directory path on the current system. :f does the same for a | file path. Both are needed because on VMS a directory name has a | different syntax than a file name. | | There are a few shallow problems, like the fact that these modifiers | don't work in the presence of other modifiers, and that a path must be | assigned to a variable before it can be translated. More importantly | there are some deep problems. The most significant is that once a name | has been translated and assigned to another variable that other | variable cannot be appended to again. E.g., | | x = /foo/bar ; | y = $(x:d) ; | | . | | $(mkdir) $(y) ; # y is used as a directory | | z = $(y)/file ; # this is wrong because y has already because translated | w = $(z:f) ; | | | So you must keep an untranslated variable around and always concatenate | onto it. | | Anyway, this scheme is more cumbersome that I would wish, and I would | like another. I would be willing to donate the code I have that does | the translation. | | | -Thanks, David davi...@template.com | |

From Seba...@mail.sema.co.uk 20 Aug 96 21:33:00 GMT Date: 20 Aug 96 21:33:00 GMT From: Seba...@mail.sema.co.uk Seba...@mail.sema.co.uk Subject: <none>

Thanks for the prompt response. It's reassuring to know it's not the way I am using Jam.

Did you know about the MCR command on VMS ?

MCR location:program p1 p2 p3

is equivalent to

program :== $location:program.exe program p1 p2 p3

Note that MCR defaults to SYS$SYSTEM to find the program, but [] can be used for the current directory. [Simple to use, but finding documentation on MCR is another matter !]

Also on VMS, MMS has the following syntax for expressing library depends:

library.olb(module=filename) : loc:filename.c

The module name an object file is stored under in a library is not necessarily the same as the source file name stem, which is why the above syntax is required. Referring back to a previous mail about very_long_file_names in Unix libraries, I wonder whether a similar syntax would be helpful in Jam ? (Or is it there and I missed it...)

HTH -- Sebastian Bazley email: Seba...@mail.sema.co.uk