From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-05-03 03:45:05
David Abrahams wrote:
> ----- Original Message -----
> From: "Rene Rivera" <grafik666_at_[hidden]>
> > This is one of the things that Vladimir pointed out that I need to
> fix. If
> > removing it for now works for you great :-)
> I had to make a bunch of other changes. We are now almost in a working
> state, but I will leave the rest to you if you can do something tonight.
> The current output is attached.
There are two outstanding issues.
First, we (well, Rene actually) has switched to using absolute names for
project modules. I belive this is mistake:
1. Users would not like absolute names if diagnostics, and converting them
back is at least as hard as using relative names in the first place.
2. I have project.jam version which uses relative paths already.
I'm likely to just commit my changes -- CVS would allow to revert them, if
Second, I don't know how David has produces the output, but in my experience,
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?
> > Now that you pointed out we
> > should normalize all paths to the os.path format I'll take that into
> > when fixing this.
> Please note, that's NOT what I meant!
> What I meant was that os.path forces its users to pass "normalized
> paths" to certain functions in order to get them to work properly, and I
> think that's a mistake. It forces users to be aware of path
> normalization at all times and to constantly switch between 'normalized'
> and 'native' representations.
Don't switch! Just call 'os.path.make' whenever you want to use any native
> 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 that's
> easy to get wrong ( path root ). I am wondering why we don't use the
> built-in :R= syntax instead
path1 = ../../bar ;
> * os.path.join seems to do some work to remove redundant .. elements,
> 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 in
> some paths that are used as, e.g. Jamfile identifiers, and that we'll
> fail to recognize the equivalence of different Jamfiles and load them
> multiple times.
Do you have a case where os.path functions either return paths that are not
normalized or when two normalized paths are in fact equvivalent?
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