From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-03 08:21:52
David Abrahams wrote:
> > Don't switch! Just call 'os.path.make' whenever you want to use any
> > native path.
> I'm still very unhappy with this arrangement.
It's bad, but I don't understand you. I don't think it's too hard. For
example, you talk about bugs in project.jam. But when I initially decided to
support relative path for jamfile, I run in problems because of native paths
and $(foo:D) which leave empty strings. Changing it to use os.path was quite
fast and everything started to work. So my experience is that os.path is
Quoting from another message:
> The easy solution for this (which is how I envisioned os.path when I
> started it) is to eschew the obscure :D :R, etc. syntax and use rules
> defined in os.path such as root_relative_path. If os.path always gives
> back valid native paths, there is no problem and its users don't have to
> think about whether a path is normalized or not.
So, every rule is os.path might work by
1. converting everyting to internal form
2. doing what it does now
3. returning the native form
Do you mean something like that?
> > > * root_relative_path takes its arguments in an unintuitive order
> > > easy to get wrong ( path root ). I am wondering why we don't use the
> > > built-in :R= syntax instead
> > path1 = ../../bar ;
> > $(path1:R=/home)
> ...and what don't you don't like about this? the fact that it allows
> you to form an illegal path with redundant info in it? ;-)
Yes, because once you allow ".." inside paths it possible to have two
different spellings, pointing to the same location, and I'm greatly scared of
this situation. With some early version of project.jam it was a nightmare.
> OK, suppose we had a terser name in os.path such as "root"? It's just a
> bit too cumbersome for a common operation this way.
> And, though I guess
> I thought the analogy with python was cute when I named it, I don't see
> a reason for the "os." prefix. Maybe this module should just be
Well, this is reasonable as well. Only we'll loose revision history... (wish
we were using Subversion instread of CVS).
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