From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-03 07:40:33
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> Second, I don't know how David has produces the output, but in my
> the only way is to copy "new/boost-build.jam" to "test". Otherwise,
> boost-build.jam from v1 will be picked. Can we do something better?
Actually I put a boost-build.jam into the test directory also, but
forgot to check it in. I don't see anything wrong with having it there,
so it's now checked in.
> Don't switch! Just call 'os.path.make' whenever you want to use any
I'm still very unhappy with this arrangement.
> > BTW, I have these other issues with os.path:
> > * naming conventions: some_rules_use_underscores
> Fixed that locally.
> > * 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 ;
...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? ;-)
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
> > * os.path.join seems to do some work to remove redundant ..
> > but other functions do not.
> Which other functions do you mean? Other functions just can't intoduce
> in the middle.
> > Shouldn't we have something like
> > simplify-path-tokens in this module? I am worried that .. shows up
> > some paths that are used as, e.g. Jamfile identifiers, and that
> > fail to recognize the equivalence of different Jamfiles and load
> > multiple times.
> Do you have a case where os.path functions either return paths that
> normalized or when two normalized paths are in fact equvivalent?
Nope, I'm speculating. It seems like it would be useful, but maybe not.
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