Re: [jamboost] project.jam question

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

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

Don't switch! Just call 'os.path.make' whenever you want to use any native 
path. 

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

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

- Volodya