David Turner [mailto:dturner nds.com] wrote:
> >> - Please do not make modifiers split strings
into lists around ':'
> >
> > The only modifier splitting up a string into a
list would be
> > native->portable (':F' or ':~'). The
character used for splitting is
> > the native path list separator (';' on win32 and
':' on unix). It
VMS had search list logicals to do this. However, the ','
can be used
to specify a list of files or pathnames (this is more a
convention
that most software packages adhere to. It's not directly
handled by
the file system at all).
> > would thus be mainly used for handling input to
the build process
> > where sequences of paths are pretty common and
most naturally
> > converted to jam lists (INCLUDE, LIB). I'd like
to stress
> there isn't
> > a separator like this for the portable format,
this is purely an
> > artefact of native paths and the :F modifier.
> >
> > I don't see a reason why this couldn't be in a
separate modifier,
> > except that the split behaviour is probably the
Path of
> Least Surprise
> > for people on the platforms affected.. 
> >
> That's sound very reasonable, sorry for jumping so
quickly on
> this ship
> >> - second, it's likely to result in
unexpected behaviour for
> >
> > Is this still valid with the expanded description?
I'm not sure I
> > understand the risk here?
> >
> I don't think there is a risk if we limit it to
native->portable.
> >> - Why would we need to add specific support
for VMS file versions ?
> >> it seems to me that Jam already works
correctly on this platform
> >> (e.g. $(somepath:S) will return the
extension, without
> the version
> >> number)
> >
> > Which means we already have implicit support for
them, don't we?
> >
> Yes, much probably
> > I just wanted to provide the version information
for explicit
> > manipulation and to support lossless modification
on the
> > VMS->portable->VMS path. Piggybacking on the
filename is
> obviously an
> > option, except it feels a bit kludgy on VMS. Other
platforms can
> > safely ignore versions, so I don't see too much
harm with
> making them
> > explicit. I assume that a *nix/win32 project would
never see them.
> >
> I don't think that Jam (and the Jambase) itself
supports
> losless modifications when it handles pathnames. For
example,
> consider the following:
>
> SOURCE = [ Glob $(DOT) : *.c ] ; # returns
"source.c;24" ;
> OBJECT = $(SOURCE:S=.obj)
>
> I don't think that keeping the 24 in $(OBJECT) has any
> meaningful use, and I'm pretty certain it's
discarded.
>
You are correct. In this instance it would be very unhelpful
to have the version number carry across. I only brought
version
numbers up for the reason you mention below.
> Similarly, if the user passes to the build script a
filename
> containing a version number, lossless modification
would only
> make sense if the value is going to be used "as
is", instead
> of being processed (e.g. to generate other names)
>
This is most likely where the use of version numbers would
occur.
> in other words, I don't see the need to add more
VMS-specific
> code into the engine. Maybe a VMS user could enlighten
us
> regarding this -- subtle -- topic ?
I'm a full-time VMS systems programmer, but I wouldn't say
I was a full-time Jam user. Unfortunately my experience is
rather limited.
I think that the version numbers discussion has gotten a bit
skewed. I was merely saying that it was something to look
out
for. It is very easy to forget that they exist for a VMS
user
and every now and again applications that don't support it
give bad results. VMS users often input previous versions of
a file if they are making regular changes, testing and
comparing.
I think supporting both portable and native file specs. is a
good idea. I think the best thing would be to use the UN*X
pathname for the portable format. I'm not sure what that
means
for Windows users, but for VMS users it means that full
support for OpenVMS features like concealed, terminal,
rooted
and search list logicals as well as version numbers and
others
will be supported correctly. Not to mention that the Jam
developers don't have to do a whole lot of extra work to
support it as there are routines in the CRTL that do the
work
already.
Regards, Tim.
_______________________________________________
jamming mailing list - jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
|