Re: [jamboost] project.jam question

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
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.

> Now that you pointed out we
> should normalize all paths to the os.path format I'll take that into
account
> 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
multiple times.

-Dave

 ------=_NextPart_000_0091_01C1F1E4.9FB0DBD0 Content-Type: application/octet-stream;
name="c.out"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="c.out"

[Attachment content not displayed.] ------=_NextPart_000_0091_01C1F1E4.9FB0DBD0--