First off, I know similar questions have already been answered, but it’s a complex topic, and I have different requirements. The last person to ask this question comprehensively was, if you read the fine print, authoring libraries (plugin/mods) as his work product, to loaded in one exe. I’m consuming libraries, have multiple exe’s, and am interested in controlling disk space usage.
I’m a hobby game developer. Several libraries I use (or may use) across projects are very large. Ogre is 1.5 GB; QT5 is 2.6 GB, for example. My executable projects (game prototypes) consuming these dependencies are often exploratory efforts, so they are numerous and of both long and short project lifetimes. I don’t want to copy all these dependencies into every project that uses them.
I’m working on simplifying my workflow for creating new game projects. Currently I have all my library dependency folders at the same top-level as game executable projects all together under my CLionProjects/ folder. To make sure the libraries are found where I built them, I’ve been setting variables just above find_package, such as “OGRE_DIR” or “LIBXML2_INCLUDE_DIR” + “LIBXML2_LIBRARY” to point to libraries’ cmake-build-debug directories or *Config.cmake files. (It’s only just started to make sense to me, after recent reading, what the difference is between pointing to *Config.cmake scripts or setting variables directly; I arrived at the latter for LIBXML2 because I couldn’t get the former approach to work.)
I recently learned about the “-C foo.cmake” commandline option, which I realized I could use in lieu of hard-coding these path hints in my executable CMakeLists.txt. I created a(nother top level) folder called “Common” and created “Common\Settings.Debug.cmake” and “Common\Settings.Release-Emscripten.cmake” scripts. Then I can just pass these to each new project and target configuration. Settings.Release-Emscripten.cmake also affords a convenient place to set CMAKE_TOOLCHAIN_FILE, instead of passing it on the CMake commandline. (CLion only provides a tiny one-line box for configuring the CMake commandline in Settings, so it’s not very ergonomic to pass many things here. If I can pare things down to ONE “-C …..\Common\Settings..cmake” argument and throw everything else over the fence into that settings script, it makes things much more manageable.)
As implied, so far I’ve been “reaching into” the cmake-build-debug or cmake-build-release-emscripten build folders to get ahold of compilation products for linking, and I guess the headers from the project source dir come along for the ride (just didn’t work with LibXML2 as previously mentioned, and I had to explicitly set its *_INCLUDE_DIR variable). While I suspect I should be using “install” targets, my reasoning is that in a counterfactual world where these libraries were part of one source tree in my executable, they’d be linked this way in the overall build anyhow. I don’t understand what benefit an intermediate install step, copying the files somewhere (in the process using even more disk space), gives me if I’m not referencing them anywhere else on my system outside the walled-garden of my CLionProjects/ folder.
The other reason I have for being leery of “install” is the toolchain environment(s) I’m working with. My Debug build environment is Msys2/MinGW on Windows, with gcc (NOT Visual Studio). Msys2 is awesome but sort of neither fish nor fowl when it comes to library install locations. If detected as “Windows”, is it “C:\Program Files”? (Please, God no.) Is it “/usr/bin”? “opt/somewhere”? Through CLion, maybe the install step goes to another subfolder of or like cmake-build-debug (again begging the question, what’s the difference between this and linking in the build folder directly). Or maybe it does nothing.
Or maybe the install goes to a location that actually overwrites the Msys2 built-in version of a library, and now system packages are breaking all over. This happened to me, twice. Msys2 uses a rolling release model without version pinning or reverting, so fixing the situation means updating, which updates other things, and so on. This in turn causes compilation errors in user projects built from source; you get to play “what did they deprecate/remove/rename/move this time?” and spelunk in mailing lists for projects you wish you didn’t have to know existed. One time I couldn’t build with gcc until JetBrains released a new version of CLion, because MSys2 or MinGW guys had moved the system C++ headers to a new subdirectory CLion didn’t know about.
But I guess you can change the default install directory though? Obviously must be the case, although, to be clear I didn’t know that before. Actually I still don’t know how much control I have versus the library author and how the mechanism works. For some but not all libraries I’ve built from source, the “install” step is as much an afterthought or “here be dragons” for them as it is for me.
All that’s a round-about way of floating the idea, if I must install maybe I can install all the libraries to a subdirectory (split out by Debug, Release-Emscripten, etc.) of the “Common” folder I’ve already created to hold my settings files? Does that sound right?
In the other similar thread I mentioned in my first paragraph, the user was advised to make a subfolder of the executable project itself be the install target of the libraries. However bear in mind, his use-case was multiple libraries (that he wrote) to be loaded by one executable. For my case I really don’t want to run installs of order N libraries times M executable project destinations. That’s hardly better in disk space, and worse logistically, than duplicating dependencies per project.
Another option that occurs to me (and it seems like CLion is halfway there anyway), can I just… install my libraries over my library projects’ own cmake-build-* directories? Like, make the installed .a and .dll files go to where they already are from the build, and the only new thing a copy of the “include/” folders show up under cmake-build-*? That way any custom-logic run during the install step would be run, but it wouldn’t use extra disk space or time copying binary files that already exist in the build location. (I was being a bit coy saying I don’t understand any benefit - I can imagine install steps might include other logic - but I’m not aware of any specific cases my libraries are taking advantage of that.)