Re: bbv2 path module questions

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

Hi again,

"Vladimir Prus" <ghost_at_[hidden]> wrote in message
news:200410221429.20965.ghost_at_cs.msu.su...
>
> Hi Johan
>
> > 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>. ;

OK. That's in itself not a big deal. However, there's more to it depending
on which compiler is used. I only have experience with HP's (formerly
compaq, formerly dec) cxx 6.5 compiler. The following explanation is
probably a bit messy:

1. To be able to use include statements using directories, e.g. "#include
<boost/thread.hpp>" the include paths passed to the compiler must be in a
special format (which is not native), e.g.:

cxx ... /include=("/boost_root") <= quotes mandatory

in the above statement "boost_root" must be a VMS concealed logical, i.e. it
is a definition of a "virtual drive", actually pointing to a directory.
Example:

define/concealed BOOST_ROOT "disk$user:[tools.boost.]"

After the above definition is made it is possible to use statements such as
"type boost_root:[tools.build.jam_src]jam.c".

2. Using "." in the include statement is ok and works as expected (however I
would suspect that .. does not).

3. All multi-valued parameters to the compiler must be passed using the
format /param=(value1,value2,...). If multiple switches are provided (e.g.
/param=value1 /param=value2) only the last definition will be used =>
include statements must be in the form "/include=(path1,path2,...)".

I'm not sure of the implications of all this, especially when it comes to
handling the automatic dependency scanning (you can't simply use
<include>/boost_root, as that is not a valid native path).

Do you have any suggestions on how to proceed with this?

>
> > - 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.
>
> Oops!
>
> > I've thus limited myself to assume that the file part of a portable path
> > has to match "^[^\.]+\..*$".
>
> Essentially, that it has a dot?

Essentially, that is has one or more of non-dot characters, followed by a
dot, optionally followed by whatever.

I was also considering some kind of escape sequence to tag part of the
portable path spec as a file; perhaps "/disk:/dir/&file;file" in this
particular case. It requires a bit more effort but feels a bit more robust.

>
> > 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
> idea.

Ok, think I'll go with that for the time being.

>
> > 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.

Ok.

// Johan