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
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 ...
Answer
#3: Post edited
- 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
- Whenever I've worked with CMake-based projects, the structure has been something like this:
```projectsrc // typically this is a source control working directoryCMakeLists.txtproject_1.cppproject_2.cpplibAlibA.cmakelibA_1.cpplibA_2.cpplibBlibB.cmakelibB_1.cpplibB_2.cppbuild // 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
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.