On 5/10/2012 9:30 AM, lcaminiti wrote:
I have a general question about what's the best way to include files that results in faster compilation time.
In my example, I have *a lot* of files that use different parts of Boost.Preprocessor. Each header includes the specific Boost.Preprocessor headers that it needs. As a results the same Boost.Preprocessor header and #included many times (50+?) even if the including has no effect after the first inclusion. Furthermore, at the end essentially all Boost.Preprocessor header get included.
This way is more module in that each single file includes all the headers that it needs. But, does that slow down compilation? Would it be faster to just #include<boost/preprocessor.hpp> just once into a front-end header that then includes all my single header files? (Maybe with modern compilers and file-systems this makes no difference?)
This is the same-old-same-old and applies to everything, not just the pp-lib. The way to solve this is with some sort of module mechanism in the language--which is difficult to do correctly. Regarding boost-pp specifically, even if you did include <boost/preprocessor.hpp>, the library itself pulls in specific dependencies. I personally _never_ use these "group" headers with pp stuff (and try to avoid it with non-pp stuff). The real reason for that is not compilation performance but to minimize physical dependencies and minimize the visibility of names (another potential benefit of a module mechanism). I'm not a terribly big fan of auto-dependency generation schemes. I actually prefer to make an explicit choice about whether to introduce a dependency. On the other hand, I do like automatically *verified* but explicit dependencies. For a build system, what I'd actually want (in addition to the usual) is that 1) there is a means to specify transitive dependencies such as includes--makefiles are horrible at this without using some form of automatically generated dependencies which cannot always be achieved, 2) a means of specifying iterative bootstrapped scenarios (e.g. LaTeX), and 3) each build action is executed in an environment where only the specified dependencies "exist"--which would provide the verification. Regards, Paul Mensonides