what is the proper use of the CMake “project” directive

前端 未结 3 1457
悲哀的现实
悲哀的现实 2021-02-15 02:09

I have a large-ish codebase which builds several dozen libaries and several executables.

The codebase is broken down hierarchically and libraries are build at pretty muc

3条回答
  •  借酒劲吻你
    2021-02-15 02:24

    Firstly, it enables you to use _BINARY_DIR and _SOURCE_DIR, but that's not the main advantage. If you give CMake a project name then it will generate build targets for each of the sub-projects in their own directories. This means that whether you're using GNU Make, Eclipse CDT, XCode, or any of the other supported generators you can build sub-projects individually. For instance with GNU Make each sub-project has its own full build system from it's own directory.

    You can access the current project name through PROJECT_NAME, and the root project name by CMAKE_PROJECT_NAME.

    Edit: I've just realised the below will be standard CMake behaviour for any of its build targets whether they're projects or not. I'll keep it here for general information but it is not pertinent to the answer:

    Assume I have a C++ library, and I can generate three binary executables; Main and tests/test1, and examples/ex1. I can either run make in the directory I called CMake from with the ALL target, run make ex1, or I can change directory to examples/ and build the examples with make from that directory. This will build all of the dependent projects and libraries even if they're somewhere else in the directory structure but won't build Main or tests/test1 or any libraries that they depend on that examples/ex1 doesn't. If I then run make from the main directory, it won't rebuild any of the libraries that examples/ex1 depends on unless their source has changed.

提交回复
热议问题