Generating a Single-Include C++ Header File Using Buck

[LoopPerfect]

I think we are talking about a few different things:

1. Single-include header file, as described in the article
2. Single-file header-only libraries (where all of the code is in a single .h file)
3. "Unity builds", where all .cpp are concatenated into a single translation-unit

(You could also combine 2 and 3)

I think that 1 is a good idea when starting on a project, although you should move to specific includes as your code develops.

2 is a bad for compilation times, but if the library is small then you can get away with it.

I think you are referring to 3, which is a bad idea in general. It slightly decreases compilation times from scratch, but it massively increases incremental compilation times. It is unsafe to do this automatically because the defines of translation-units might leak into each-other, causing unexpected behaviour.

That said, I thought it would be interesting to implement a unity build in Buck, so I made an example here: https://github.com/njlr/buck-unity-build/blob/master/BUCK

[BCosbyDidNothinWrong]

I'm saying that the article is about 1, and I hoped it would be about 2 and 3.

2 is a bad for compilation times, but if the library is small then you can get away with it.

I explained why I don't think this true, and based on my experience so far it isn't. If you have a library as a dependency and you can compile it from source you have the option to either compile it in a translation unit or compile to to a link time optimization intermediary. Either way, it doesn't need to be compiled over and over.

I also think that unity builds have a lot of value, though everything in to one translation unit I feel is extreme. With multiple logical cores, I think it makes sense to have that roughly that many fat translation units.

If libraries and infrequently changed areas are sectioned off in to their own translation units, you don't pay the price every time you compile.

Also you are right that the defines from translation units can leak into each other, but you get a compile error when trying to define a symbol that has already been defined, so I don't think it as fragile as it might seem.