Re: [jamboost] project.jam question

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

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

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
that's
> > 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? ;-)

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
"path.jam"?

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

Oh, OK.

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

Nope, I'm speculating. It seems like it would be useful, but maybe not.

-Dave