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.