Re: [boost] questions regarding dependency reports(s)

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.