Re: [jamboost] Re: boost.build-v2: usage-requirements for header-only libs?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-29 07:31:36

Michael Stevens wrote:
> Vladimir Prus wrote:
> > David Abrahams wrote:
> >
> > In fact, immediately after I went online after replying Peter, I
> > realized we
> > can support this in a simple way in V2.
> >
> > alias aHeaderOnlyLib : : : : <include>include ;
> >
> > Now, alias does not support usage requirements, but it's trivial to
> > add. Any
> > objections to this approach?
> >
> > W.r.t. projects: the 'usage-requirements' attribute on projects have
> > effect
> > only on targets declarated in that project, so <use>/boost does not work.
>
> I was thinking about the issue of library header files a bit further. In
> particular with composite builds with include headers from disparate
> projects.
> Let me give a concreate example. I have a library and example source
> that I distribute (actually called) Bayes++. This library reliese on
> Boost for several header only libraries. When a users wants to build my
> examples they must follow a few instructions so the build succeds in
> finding the Boost headers.
>
> This last step is fraught with danger! A simple typo or renamed
> directory will result in failure. The problem for the poor user is that
> it only shows up at a very late stage. When the compiler #include the
> first header from Boost. The usually result in the normal indecipherable
> stream of errors.
>
> My ideal solution is that the error comes much earlier (and more
> meaningfully) from the build system. It this case the build system would
> need to know about the set of header files that can be included from the
> library.

The arrangement that I envisoned is that:
1. The external library has proper usage requirments which specify <include> 
properties.
2. The users of main package specify location of external libraries via 
"use-project". If they make a type, Boost.Build will tell them.

> Obviously the build system can do more then just issue (hopefull
> meaningful) error messages. It can also determine the necessary build
> dependencies to these headers.

Do you mean build system can download then necessary files/libraries?

> At the moment I don't have a clear notion of how best to implement this.
> It would seem logicaly that the library itself sepecify these header
> dependancies. That is the present BOOST_ROOT/Jamfile would specify the
> full set of headers in BOOST_ROOT/boost.

So far it only specifies <include> property. Why listing all headers is 
necessary?

- Volodya