Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

62%
+3 −1
Q&A How to do "out-of-source" build properly with cmake?

Whenever I've worked with CMake-based projects, the structure has been something like this: project src <-------- typically this is a source control working directory CMakeLists.txt ...

posted 4y ago by Hyperlynx‭  ·  edited 4y ago by Hyperlynx‭

Answer
#3: Post edited by user avatar Hyperlynx‭ · 2020-12-16T02:37:52Z (almost 4 years ago)
  • Whenever I've worked with CMake-based projects, the structure has been something like this:
  • * project
  • * src <-------- typically this is a source control working directory
  • * CMakeLists.txt
  • * project_1.cpp
  • * project_2.cpp
  • * libA
  • * libA.cmake
  • * libA_1.cpp
  • * libA_2.cpp
  • * libB
  • * libB.cmake
  • * libB_1.cpp
  • * libB_2.cpp
  • * build <-------- CMake output goes here!
  • * runCMake.sh
  • My runCMake.sh then looks like this:
  • ```
  • #!/bin/sh
  • CMAKE= wherever it's installed
  • BUILD=`pwd`/build
  • SRC=`pwd`/src
  • mkdir -p $BUILD
  • cd $BUILD
  • $CMAKE $DEBUG_OPTS $SRC
  • ```
  • In other words, I have one build directory that stores the output of everything. Note that this directory serves to store three different types of things:
  • 1. CMake's own configuration files for this project (eg the CMakeCache).
  • 1. The project files that will be used by your build tool to actually build the software (eg Makefiles, or MSVC .sln and .proj files)
  • 1. The actual output of compiling and building.
  • I honestly don't know whether it is possible to store those three separately from each other and, if so, whether you can split up where the compilation output is stored. Nor, alternatively, how to split it up so that you have multiple build directories each of which stores those three things but only for a subset of your project (ie one for each library and one for your main application).
  • But I don't know why you'd want those things, either.
  • Whenever I've worked with CMake-based projects, the structure has been something like this:
  • * project
  • * src <-------- typically this is a source control working directory
  • * CMakeLists.txt
  • * project_1.cpp
  • * project_2.cpp
  • * libA
  • * libA.cmake
  • * libA_1.cpp
  • * libA_2.cpp
  • * libB
  • * libB.cmake
  • * libB_1.cpp
  • * libB_2.cpp
  • * build <-------- CMake output goes here!
  • * runCMake.sh
  • My runCMake.sh then looks like this:
  • ```
  • #!/bin/sh
  • CMAKE= #wherever it's installed
  • BUILD=`pwd`/build
  • SRC=`pwd`/src
  • mkdir -p $BUILD
  • cd $BUILD
  • $CMAKE $DEBUG_OPTS $SRC
  • ```
  • In other words, I have one build directory that stores the output of everything. Note that this directory serves to store three different types of things:
  • 1. CMake's own configuration files for this project (eg the CMakeCache).
  • 1. The project files that will be used by your build tool to actually build the software (eg Makefiles, or MSVC .sln and .proj files)
  • 1. The actual output of compiling and building.
  • I honestly don't know whether it is possible to store those three separately from each other and, if so, whether you can split up where the compilation output is stored. Nor, alternatively, how to split it up so that you have multiple build directories each of which stores those three things but only for a subset of your project (ie one for each library and one for your main application).
  • But I don't know why you'd want those things, either.
#2: Post edited by user avatar Hyperlynx‭ · 2020-12-16T02:36:39Z (almost 4 years ago)
  • Whenever I've worked with CMake-based projects, the structure has been something like this:
  • ```
  • project
  • src // typically this is a source control working directory
  • CMakeLists.txt
  • project_1.cpp
  • project_2.cpp
  • libA
  • libA.cmake
  • libA_1.cpp
  • libA_2.cpp
  • libB
  • libB.cmake
  • libB_1.cpp
  • libB_2.cpp
  • build // CMake output goes here!
  • runCMake.sh
  • ```
  • My runCMake.sh then looks like this:
  • ```
  • #!/bin/sh
  • CMAKE= wherever it's installed
  • BUILD=`pwd`/build
  • SRC=`pwd`/src
  • mkdir -p $BUILD
  • cd $BUILD
  • $CMAKE $DEBUG_OPTS $SRC
  • ```
  • In other words, I have one build directory that stores the output of everything. Note that this directory serves to store three different types of things:
  • 1. CMake's own configuration files for this project (eg the CMakeCache).
  • 1. The project files that will be used by your build tool to actually build the software (eg Makefiles, or MSVC .sln and .proj files)
  • 1. The actual output of compiling and building.
  • I honestly don't know whether it is possible to store those three separately from each other and, if so, whether you can split up where the compilation output is stored. Nor, alternatively, how to split it up so that you have multiple build directories each of which stores those three things but only for a subset of your project (ie one for each library and one for your main application).
  • But I don't know why you'd want those things, either.
  • Whenever I've worked with CMake-based projects, the structure has been something like this:
  • * project
  • * src <-------- typically this is a source control working directory
  • * CMakeLists.txt
  • * project_1.cpp
  • * project_2.cpp
  • * libA
  • * libA.cmake
  • * libA_1.cpp
  • * libA_2.cpp
  • * libB
  • * libB.cmake
  • * libB_1.cpp
  • * libB_2.cpp
  • * build <-------- CMake output goes here!
  • * runCMake.sh
  • My runCMake.sh then looks like this:
  • ```
  • #!/bin/sh
  • CMAKE= wherever it's installed
  • BUILD=`pwd`/build
  • SRC=`pwd`/src
  • mkdir -p $BUILD
  • cd $BUILD
  • $CMAKE $DEBUG_OPTS $SRC
  • ```
  • In other words, I have one build directory that stores the output of everything. Note that this directory serves to store three different types of things:
  • 1. CMake's own configuration files for this project (eg the CMakeCache).
  • 1. The project files that will be used by your build tool to actually build the software (eg Makefiles, or MSVC .sln and .proj files)
  • 1. The actual output of compiling and building.
  • I honestly don't know whether it is possible to store those three separately from each other and, if so, whether you can split up where the compilation output is stored. Nor, alternatively, how to split it up so that you have multiple build directories each of which stores those three things but only for a subset of your project (ie one for each library and one for your main application).
  • But I don't know why you'd want those things, either.
#1: Initial revision by user avatar Hyperlynx‭ · 2020-12-16T02:33:16Z (almost 4 years ago)
Whenever I've worked with CMake-based projects, the structure has been something like this:


```
project
    src     // typically this is a source control working directory
        CMakeLists.txt
        project_1.cpp
        project_2.cpp
        libA
            libA.cmake
            libA_1.cpp
            libA_2.cpp
        libB
            libB.cmake
            libB_1.cpp
            libB_2.cpp
    build    // CMake output goes here!
    runCMake.sh
```

My runCMake.sh then looks like this:
```
#!/bin/sh
CMAKE= wherever it's installed

BUILD=`pwd`/build
SRC=`pwd`/src

mkdir -p $BUILD
cd $BUILD

$CMAKE $DEBUG_OPTS $SRC

```

In other words, I have one build directory that stores the output of everything. Note that this directory serves to store three different types of things:

 1. CMake's own configuration files for this project (eg the CMakeCache).
 1. The project files that will be used by your build tool to actually build the software (eg Makefiles, or MSVC .sln and .proj files)
 1. The actual output of compiling and building.

I honestly don't know whether it is possible to store those three  separately from each other and, if so, whether you can split up where the compilation output is stored. Nor, alternatively, how to split it up so that you have multiple build directories each of which stores those three things but only for a subset of your project (ie one for each library and one for your main application).

But I don't know why you'd want those things, either.