0

We have a very big codebase (more than 3K translation units) and despite it being subdivided into small libraries, there is no distinction between private headers and public headers.

We use CMake as a build system and we are building on Linux, so my understanding is that every symbol is exported by default and when the linker has to choose which symbol to link, it has to choose among all of them, even those which are not really part of a library public interface.

If we would separate for each library which headers are private and which headers are public, and heavily use CMake PUBLIC and CMake PRIVATE dependency type when expressing dependencies among libraries, would there be any benefit in terms of linking time? Or would it still be the case that the linker just sees everything and has to perform a full search?

thebugger
  • 123
  • 6
  • 1
    If your "small libraries" are **static** ones, then true linkage is performed only once, when all these libraries are combined into an executable (or shared library). That is, PRIVATE/PUBLIC **linkage** doesn't affect on the linkage process. In case of **shared** libraries, every time a linker links with one of that libraries, it searches symbols in its "shared" dependecies too. That is, unnecessary PUBLIC **linkage** would add a library into the linker's command line, but that library would be examined by the linker even in PRIVATE case. PUBLIC/PRIVATE **headers** have no effect on linkage. – Tsyvarev Mar 01 '23 at 12:41
  • Not an answer to your question, but for your quest to speed up compilation you can take a look here: https://stackoverflow.com/questions/373142/what-techniques-can-be-used-to-speed-up-c-compilation-times – Frodyne Mar 01 '23 at 13:26
  • 1
    I wouldn't expect moving things in headers to affect linker speed, it'll only change the compile speed – Alan Birtles Mar 01 '23 at 14:35

1 Answers1

0

... would there be any benefit in terms of linking time?

Nope, it's another thing. There are many things you can do to reduce build time. First, that came to my mind:

  • use PCH wisely
  • try unity builds (be ready to fix your code)
  • reduce the amount of included headers (IWYU, may help but could be not easy)
  • review PUBLIC/ PRIVATE dependencies accurately to be sure only necessary libs are listed as dependencies
  • reduce the number of exported symbols via visibility control (and maybe ld-scripts as well)
  • try ccache

… this is the first things to do.

zaufi
  • 6,811
  • 26
  • 34
  • Isn't OP asking specifically about link time? PCH, unity, etc. are irrelevant in this case. – yugr Mar 02 '23 at 03:05
  • @yugr When someone talks about _a very big codebase_ I assume he wants to reduce build time. Link time is part of it and unfortunately, there are not many things to do w/ it (especially when he didn't disclose details) – zaufi Mar 03 '23 at 04:16