I have an interesting use case involving static libraries. Let’s say a particular target needs to link to a set of static libraries that isn’t known when CMake is run. The project builds a tool which scans files and works out a set of static plugin libraries that need to be linked to the target (only needed for static builds because the target can load the plugins dynamically at runtime otherwise). The problem is that CMake wants to know the set of libraries at configure time, but the tool that works that out is built later.
A potential solution to this is to tell CMake to add a response file to the linker command line and define a custom command that invokes the tool to write out that response file. The dependencies can be defined to ensure things happen at the right time and are re-invoked when necessary. I’ve got a proof-of-concept working which demonstrates the principle, at least on macOS, but as far as I can tell, it would work with all mainstream linkers.
The questions I have around this technique are the following:
- CMake currently appears to define an undocumented (so presumably internal) variable
CMAKE_<LANG>_RESPONSE_FILE_LINK_FLAG. Would there be any reason we wouldn’t want to document this and support it going forward? If the variable is empty or not defined, that means the linker doesn’t support response files (seems that most linkers do, except for maybe the TI or the gcc 3.x front end, neither of which I think would be a deal-breaker for my use case).
- Can anyone poke holes in why this wouldn’t work reliably?
- Are there any other robust ways to link to a set of libraries that are computed at build time?
My use case spans a lot of platforms, including embedded, so it may be challenging to get something that works everywhere.
I don’t know if it would make sense for CMake to offer some kind of direct support for this, but it’s a scenario I’ve encountered more than once. Sometimes these scenarios also involve a set of source files that isn’t known until build time too, but for this particular query, I think I can avoid that. In the past, I’ve used a dedicated sub-build that runs at configure time to get out of jail for this, but in my current scenario, that wouldn’t be practical. It is also a technique that should be a last resort, as it is messy and inefficient.