Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-09-24 01:22:17


"David Abrahams" <dave_at_[hidden]> wrote in message
news:090101c262b2$b0d22ce0$6701a8c0_at_boostconsulting.com...
> From: "Edward Diener" <eddielee_at_[hidden]>
>
>
> > I started a thread about a month ago mentioning that the header file
> > dependencies were out of date. Has there been any work to bring them up
> to
> > date ?
>
> I doubt it. Last I remember we had a discussion of some problems without
> any good resolution.
>
> > I think a good other way to specify dependencies is to make a tree of
> what
> > general implementations are dependent on other general implementations,
> and
> > then list all of the header files for a given implementation. This would
> > allow someone distributing a particular implementation with their code,
> > let's take boost::function as an example, to also distribute all the
> header
> > files for the implementations which boost::function uses ( and of course
> > recursively for any of those other implementations ), and would give
> > distributors a fighting chance of successfully distributing something
> less
> > than the entire Boost header files. I realize that config and its header
> > files must be distributed with everything, but I don't think it should
be
> > necessary to have to ditsribute all of the headers each time a small
> number
> > of implementations are used.
> >
> > An example of such a useful tree format, would be:
> >
> > boost::function
> > boost::mem_fn
> > boost::xxx
> > etc.
> > boost::function header file
> > etc.
> >
> > boost::mem_fn
> > boost::yyy
> > etc.
> > boost::mem_fn header file
> > etc.
> >
> > etc.
> >
> > Such a tree would have the minimum amount of redundancy, but by
following
> > through starting at a particular implementation, one could know what
> header
> > files to distribute, even if one distributed a few extra header files
for
> a
> > particular implementation which might not be needed by actual usage. I
> > consider this type of dependency tree easier for the purposes of
> > distribution than an accurate header-by-header tree, and it should
> certainly
> > be easier to create for users of Boost implementations.
>
> Sure. I think some experimentation with different approaches will be
needed
> before we find the most useful format.
>
> Suggestion: if you want to see results in this area, why don't you try
some
> experiments with different styles and post them for discussion? I don't
> think we're going to end up with anything worthwhile until someone who
> really cares about this decides to take responsibility for it.

I care about it but I am neither knowledgeable enough about the wide variety
of libaries which are in Boost to know what depends on what nor do I, for
personal reasons, have the time to do such a thing. I was hoping someone who
is more knowledgable and has the time would be willing to do it. The style I
favor is the one I have previously posted in this thread. It would allow
distributors of an implementation to know what other implementations have to
be distributed and it would list all the header files for any given
implementation, thus making it possible for a distributor using a particular
implementation to distribute less than the full header file directory
structure. I found it very annoying that in a distribution of mine which
uses boost::function and boost::bind, I had to distribute the full header
file directory structure because trying to figure out what subset of the
full header file directory is used by those two implementations and their
dependencies was too difficult and time-consuming to do. With my suggestion,
such a task would be very straightforward. I have a feeling that other
programmers distributing code, which uses just a subset of the many
implementations which Boost encompasses, would find such a solution very
beneficial also.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk