From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-02 14:21:17
----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
> This is one of the things that Vladimir pointed out that I need to
> 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.
> 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.
BTW, I have these other issues with os.path:
* naming conventions: some_rules_use_underscores
* 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
* os.path.join seems to do some work to remove redundant .. elements,
but other functions do not. 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
------=_NextPart_000_0091_01C1F1E4.9FB0DBD0 Content-Type: application/octet-stream;
[Attachment content not displayed.] ------=_NextPart_000_0091_01C1F1E4.9FB0DBD0--
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