Re: [jamboost] Re: How to suppress toolset in target paths?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-14 04:26:28

On Friday 10 December 2004 19:39, David Abrahams wrote:
> Vladimir Prus wrote:
> > On Thursday 09 December 2004 20:21, David Abrahams wrote:
> >> I didn't notice this before, but now I am seeing C++ toolsets showing up
> >> as relevant features in my documentation builds:
> >>
> >> MkDir1 libs\numeric\mtl\doc\bin
> >> MkDir1 libs\numeric\mtl\doc\bin\gcc-3.2
> >> MkDir1 libs\numeric\mtl\doc\bin\gcc-3.2\debug
> >> docutils.html libs\numeric\mtl\doc\bin\gcc-3.2\debug\plan.html
> >> docutils.html libs\numeric\mtl\doc\bin\gcc-3.2\debug\sow.html
> >>
> >> What have I done wrong?
> >
> > Nothing, it's the only behaviour currently. Now, there are two approaches
> > how to deal with it.
> >
> > 1. The <in-path> feature we've discussed previously, that should control
> > which properties how up in path and which don't. Problem: it must be set
> > on each target.
>
> Having a terrible time finding any docs for that feature 

Sure, it's not yet implemented. I think we never finished the discussion.

> or even the 
> discussion history. 

I think it's

http://thread.gmane.org/gmane.comp.lib.boost.build/6601

> Can you help? My main concern is that we should be 
> able to say "not-in-path."

The idea was that <in-path> feature explicitly lists features that should be 
in path.

> > 2. Allow to specify, when declaring *generator*, the list of relevant
> > properties. When creating targets, only relevant properies will be left
> > in property-set.
> >
> > The second approach is nice because everywhere you write:
> >
> > html a : a.rst ;
> >
> > you'll have 'a.html' just in "bin". You don't need any explicit
> > <in-path>. I attach a patch which implements this idea. With that patch,
> > I get:
> >
> >
> > docutils.html bin/a.html
> >
> > PYTHONPATH=foo:foo/extras;export PYTHONPATH
> > python foo/tools/rst2html.py a.rst bin/a.html
> >
> > Comments are most welcome!
>
> I'm sorry, I'm confused about why anything explicit should have to be
> said about which properties are relevant. In BBv1 the flags rule took
> care of making properties relevant. You might only need to augment that
> information in a few rare cases.

Hmm... I was not aware of that, and you did not tell that in previous 
discussions. I think such automatic detection is very well possible.

There's one question though. In past, Jurgen said that at least for him it's 
better to have everyting built in separate directories. Say, if bison 
produces files to "bin", them "bjam --clean release" will clean those files 
too, and he did not like this.

Do we need yet another option?

- Volodya