Msys2 uses a rolling release model without version pinning or reverting, so fixing the situation means updating, which updates other things, and so on. 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. 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). Msys2 is awesome but sort of neither fish nor fowl when it comes to library install locations. My Debug build environment is Msys2/MinGW on Windows, with gcc (NOT Visual Studio). The other reason I have for being leery of “install” is the toolchain environment(s) I’m working with. 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. 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. 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.)Īs 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). (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. also affords a convenient place to set CMAKE_TOOLCHAIN_FILE, instead of passing it on the CMake commandline. Then I can just pass these to each new project and target configuration. I created a(nother top level) folder called “Common” and created “Common\” and “Common\” scripts. 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. (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.) 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. Currently I have all my library dependency folders at the same top-level as game executable projects all together under my CLionProjects/ folder. I’m working on simplifying my workflow for creating new game projects. I don’t want to copy all these dependencies into every project that uses them. My executable projects (game prototypes) consuming these dependencies are often exploratory efforts, so they are numerous and of both long and short project lifetimes. Ogre is 1.5 GB QT5 is 2.6 GB, for example. Several libraries I use (or may use) across projects are very large. I’m consuming libraries, have multiple exe’s, and am interested in controlling disk space usage. 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. First off, I know similar questions have already been answered, but it’s a complex topic, and I have different requirements.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |