From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-22 05:29:20
> 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?
No. If fact, I suspect fixes would be necessary but don't yet know where.
> - 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 "-".
I think yet. At least ".." in portable paths are allowed.
> - What about "." - is it used in portable paths at all? The VMS equivalent
> is "".
Yes, it's used. The most common usage is:
exe foo : foo.cpp : <include>. ;
> - 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 "^[^\.]+\..*$".
Essentially, that it has a dot?
> 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)
I think that on VMS, adding the dot when creating portable path is a good
> 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).
Seems reasonable to me.
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