![]() You ought to be able to pull the CMake libA project into the exeB project, and go from there. You really want to pull libA into the exeB project and work with it inline.ĬMake supports both models, at least to some extent. Not go to the libA project, change things in those files, build and install, then try it out in exeB, and iterate that a few times. If you find a flaw with your own code in libA when you're consuming it in exeB, you want to just change it and rebuild. That's usual for 2nd and 3rd party libs, but unusual for 1st party ones. The result of an 'install' is something that can be consumed by a different project, which will not be making changes to the first. There's also the issue of co-development. This means that C++ libraries must, in general, be built with the same compiler, with the same options, and against all of the same underlying libraries. We want to expose more information, like object layouts, so that things can be inlined, and optimized effectively. ![]() See, for example, FILE*.Ĭ++ is more complicated. Complex objects get passed by a pointer that erases details, and only the library manipulates them. For things with C linkage, otherwise known as OS linkage, this is pretty straightforward. They will share the same ABI for everything. There's also the assumption that things deployed via package management are broadly interoperable. That's still a terrible way to deal with the system, as cruft accumulates. In the dark ages, make install was how you installed things, although usually into /usr/local, which was reserved for the local administrator. CMake will then chose at link time which library to load based on the build configurations. ![]() You can also install a single package with multiple configurations, because IMPORT libraries can have multiple imported configurations. Since the version qualifier follows the package name, both Foo-1.0, Foo-1.1, and Foo-WhateverVersion will all be searched, and a FooConfigVersion.cmake can help CMake know which one to chose. Know that find_package(Foo) does a glob search for /(lib|share|)/Foo*. This isn't all that needs to be done, but it's a start. ![]() If given a relative path for DESTINATION, the file will be installed in $ENV/cmake) This gives good customization point when you need more complex install behavior.Ī lot of the magic lies in the file(INSTALL) command: You can insert arbitrary code into the install script using install(SCRIPT) and install(CODE). ) commands will be generated in a cmake_install.cmake in the corresponding build directory. Roughly: Each time you call install() in your CMakeLists.txt, one or more file(INSTALL. If you take a look inside the script, you'll see it executes file(INSTALL. When you run make install, it executes cmake -P cmake_install.cmake. As a developer, you won't see a lot of benefit from making install rules for your own projects, but many users will (As well as package maintainers).ĬMake installation works by generating a cmake_install.cmake script at configure/generate time. Or is this a feature most people are simply ignoring?ĭoing installs properly is an important skill and difficult task in and of itself. I feel like maybe I'm missing something important here. If you have 2 unrelated projects that both use the same external library with different configurations - what will happen when you install both? On a Linux system is it just copying what you build to some system default locations? like /usr/lib and /usr/bin? Does the workflow expect me to run "make install" as root each time? Does "installing" lose it's meaning on Windows?Įvery time I start to look into it, it seems to make everything very messy with generator functions with no added benefit for me as a developer.ĮDIT: It also doesn't seem to flow well with dependencies. I'm honestly not even really understanding the basics of why it exists. This is some concept that seems to live both in cmake and make Lately I've really tried to aggressively redo my project management so that everything is built out-of-source (b/c things are getting messier with different toolchains and targets) and i keep bumping into "installing". I've been using CMake for quite a few years now and I've always been simply generating make files or vcproj files and building my projects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |