Boost logo

Boost-Build :

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-10-22 04:20:32


Hi,

I've started out working on VMS support for the path module and have a
couple of questions:

- In a previous posting you mentioned some neccessary fixes with regards to
non-portable paths being used in the kernel module - did you change that?
- Should conversions of portable paths including the ".." into native paths
be supported (I can't see any current tests for that - maybe because the
current platforms have the same notion as the portable path for parent
directory)? The VMS equivalent is "-".
- What about "." - is it used in portable paths at all? The VMS equivalent
is "[]".
- The big question (which requires a little bit of preamble, actually):

The VMS path specification goes along the lines of disk:[dir]file, so
converting that into the portable path renders "/disk:/dir/file". Now to the
$10.000 question: How on earth could I reliably convert that back into a
native path? No can do. There's no way of knowing if the last part is
directory or file in this particular case.

I've thus limited myself to assume that the file part of a portable path has
to match "^[^\.]+\..*$". If not - I assume it's part of the path spec. I was
also considering how to perhaps lessen the problem: would it be a good idea
to always append a "." to filenames missing an extension when converting the
into portable formats, e.g.:

"disk:[dir]file" => "/disk:/dir/file." (note trailing dot)

A problem here is that the relatively new ODS-5 file system also supports
dots in path specs. To create such directories one have to use the
circumflex escape character, e.g.:

create/dir [.sub^.dir] => create subdirectory "sub.dir".

As I find this extremely confusing (imagine embedded "/" in unix directory
names) I simply won't bother to handle this (for the time being, at least).

// Johan

 


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