Subject: Re: [boost] questions regarding dependency reports(s)
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-09-26 22:40:27
On 9/26/2014 7:10 PM, Andrey Semashev wrote:
> On Friday 26 September 2014 15:35:54 Robert Ramey wrote:
>> What would it take to make a version of BCP which, given
>> an arbitrary group of source files, returns a list of headers
>> and *.cpp files which could be used to build the app?
> The main problem with bcp and header-based dependency tracking in general is
> dealing with preprocessor tricks which affect the inclusion graph. The cases
> when a macro unfolds in the header name are not uncommon. Even more
> complicated are cases when #include directives are conditioned on some tests
> like compiler version or platform or macros defined in other headers.
It gets much more complicated than that:
* You could have a header which, if it is not used, means that some
dependency is unnecessary.
* You could a conditional which, if it is not defined, mean that some
dependency is unnecessary.
* You could have a "feature" which, if it is not used, mean that some
dependency is unnecessary. A "feature" can be anything along the lines
of what people are suggesting as a sublibrary, ie. support for something
outside the mainstream use of a library.
* Nobody has talked about a most common case: a library will depend on
some particular version(s) of another library but will not work with
other versions of another library. Given that libraries usually strive
to not remove existing interfaces this usually means that a library will
depend on some minimal version on up of another library. Currently Boost
has no way to specify/track version information in Boost libraries, a
serious flaw IMO to any idea of being able to isolate a particular
library and its dependencies for the purpose of use outside of the
entire Boost tree.
While processing headers is worthwhile, I do not believe that any
dependency system relying just on that technique will ever be able to
always determine all the dependency information necessary to isolate a
library and its dependencies for every potential use case. It may work
for a very simple situation but will not scale as a library gets more
complicated and offers a number of choices how it can be used. Boost
ideally will need something better based on some sort of
meta-information which a library author will need to supply.
Of course if there is no real impetus to provide Boost library isolation
and Boost will continue to be distributed in its current monolithic way,
then the tracking of dependencies via header file analysis may be as
adequate as we want to get to a decent indication of what depends on what.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk