1## Why does bmcweb use so many headers? My build times are slow!## 2 3TL; DR, History 4 5bmcweb at one point was a crow-based project. Evidence of this can still be 6seen in the http/.hpp files that still contain references to the crow 7namespaces. Crow makes heavy use of headers and template meta programming, and 8doesn't ship any cpp or implementation files, choosing to put everything in 9include once headers. As bmcweb evolved, it needed more capabilities, so the 10core was ported to Boost Beast, and what remains has very little similarity to 11crow anymore. Boost::beast at the time we ported took the same opinion, 12relying on header files and almost no implementation compile units. A large 13amount of the compile time is taken up in boost::beast template instantiations, 14specifically for boost::beast::http::message (ie Request and Response). 15 16The initial solution that gets proposed is to just move everything as it exists 17to separate compile units, making no other changes. This has been proposed and 18implemented 3-4 times in the project, the latest of which is below. The intent 19of this document is largely to save effort for the next person, so they can at 20least start from the existing prior attempts. 21 22https://gerrit.openbmc.org/c/openbmc/bmcweb/+/49039 23 24Moving to cpp files without handling any architecture has the net result of 25making total compilation slower, not faster, as the slowest-to-compile parts end 26up getting compiled multiple times, then the duplicates deleted at link time. 27This isn't great for the end result. 28 29To actually effect the result that we'd like to see from multiple compile units, 30there have been proposed a few ideas might provide some relief; 31 32- Moving the Request and Response containers to opaque structures, so a majority 33 of code only needs to #include the interface, not any of the template code. 34 https://gerrit.openbmc.org/c/openbmc/bmcweb/+/37445 35 Doing this exposed a number of mediocre practices in the route handlers, 36 where routes made copies of requests/responses, relied on APIs that should've 37 been internal, and other practices that make this migration less 38 straightforward, but is still being pursued by maintainers over time. 39- Moving the internals of Request/Response/Connection to rely on something like 40 [http::proto](https://github.com/CPPAlliance/http_proto) which, written by the 41 same author as boost::beast, claims to have significant reduction in compile 42 time templates, and might not require abstracting the Request/Response 43 objects. 44- Reduce the bmcweb binary size to the point where link time optimization is not 45 required for most usages. About half of the bmcweb build time is spent doing 46 link time optimization, which, as of this time is required to keep bmcweb code 47 small enough to deploy on an actual BMCs (See DEVELOPING.md for details). 48 One could theoretically determine the source of where LTO decreases the binary 49 size the most, and ensure that those were all in the same compile unit, such 50 that they got optimized without requiring LTO. 51