The normal build command:
scons build/ARM/gem5.opt
places the build inside the source tree at:
build/
How to place it in a custom location?
I could not find any relevant scons options.
I asked on the mailing list and the devs showed me that the following works:
scons /any/path/that/you/want/build/ARM/gem5.opt
gem5's build system just parses the path magically, and extracts the arch and opt from it.
The build/ part is mandatory.
Tested on gem5 8e11ea0e5862f2b088b4b21c32933b623b84efcc
Related
I'm trying to build ClickHouse in CLion.
I follow the official documentation. I was able to build ClickHouse from the command line, however, I would also like to be able to build it in CLion.
The documentation doesn't give out much information on how to do that, only implies that it's possible. ClickHouse's GitHub Issues search by 'CLion' also do not offer much advice.
ClickHouse uses CMake and Ninja. The documentation mentions that one can use either Ninja or make instead of Ninja to compile in CLion.
I tried both and got many errors. For example, when running with CMake settings set to -G Ninja, I was able to build the target common but I get the following error when building the target clickhouse-client:
====================[ Build | clickhouse-client | Debug ]=======================
/usr/bin/cmake --build /tmp/tmp.CAA3nJhi8z/cmake-build-debug --target clickhouse-client
[1/7338] Generating lber-version.c
FAILED: contrib/openldap-cmake/lber-version.c
cd /tmp/tmp.CAA3nJhi8z/contrib/openldap && /usr/bin/cmake -E env bash -c "/tmp/tmp.CAA3nJhi8z/contrib/openldap/build/mkversion -v '2.5.X' liblber.la > \"/tmp/tmp.CAA3nJhi8z/cmake-build-debug/contrib/openldap-cmake/lber-version.c\""
bash: /tmp/tmp.CAA3nJhi8z/contrib/openldap/build/mkversion: Permission denied
[18/7338] Building CXX object contrib/..._/icu/icu4c/source/i18n/calendar.cpp.o
ninja: build stopped: subcommand failed.
I also use a remote toolchain in CLion to build on a server, not my laptop. Since it's a permission issue, I assume I have to run the build from sudo but I'm not sure how to do that, and searching only offers a guide on How to debug as root in CLion.
Question #2. Is it OK that after CMake loaded in CLion, I don't see any green arrows in the CMakeLists.txt in the root of the ClickHouse project? I can only see targets in the top right corner dropdown (screenshot).
Question #3. I'm also unsure how to build all the binaries in CLion. E.g. in the command line, I would just run ninja but in CLion there are so many targets, and none of them is named like build all.
Any pointers to a solution are much appreciated.
It might be helpful to someone to answer your first question.
Since you are using a remote build, the Clion first copies all source files to the remote machine. And if the option
Settings -> Build,Execution,Deployment -> Deployment -> Options -> Preserve original file permissions
is not enabled, it does not save the executable permissions to run some scripts. Which breaks the build.
Therefore, you can either enable this option and re-upload the files or set permission x manually to the files that will be logged in the error message.
The question
Debug vs Release in CMake
indicates that
cd ~/codebase
mkdir Release
cd Release
cmake -DCMAKE_BUILD_TYPE=Release ..
make
Will create the Makefile in release, and build the binary there. The intermediate .o files will be in a subdirectory of this.
However, when I do this with my project, CMake ignores the PWD that it is started from. The final target is always the directory ~/codebase/ which contains CMakeList.txt.
In the cmake-gui tool, I specified the source and build directories to be the same directory, the FQN to codebase
I'm new to CMake, and don't know how to get this to work as I expect. What should I modify to get this work as expected?
If you are using a single configuration generator (Ninja/Unix-Makefiles)
Then you need a build folder for each configuration.
Like this:
# Configure the build
cmake -S . -B build/Debug -D CMAKE_BUILD_TYPE=Release
# Actually build the binaries
cmake --build build/Debug
For multi-configuration generators it's slightly different (Ninja Multi-Config, Visual Studio)
# Configure the build
cmake -S . -B build
# Actually build the binaries
cmake --build build --config Debug
If you are wondering why this is necessary it's because cmake isn't a build system. It's a meta-build system (IE a build system that creates build systems). This is basically the result of handling build systems that support multiple-configurations in 1 build. If you'd like a deeper understanding I'd suggest reading a bit about cmake in Craig Scott's book "Professional CMake: A Practical Guide
Note:
My examples use newer cmake cli practices.
EDIT:
That question you linked to has dangerously out of date answers...
I have built libgit2 on my Ubuntu 16.04 machine, and everything seemed fine. I ran make in the /examples directory and when I try to run ./log I get the following:
./log: error while loading shared libraries: libgit2.so.26: cannot open shared object file: No such file or directory
But, in the /build folder I indeed have both libgit2.so and libgit2.so.26 so I am not really sure what I am missing. I can post more info if it is needed. I am using cmake version 3.5.1.
The Makefile in the examples will provide guidelines for usage, which should be suitable when you have actually installed libgit2 into system library locations.
To build the examples within the source directory, you should use cmake to build the examples. Given a fresh configuration:
$ mkdir build
$ cd build
$ cmake .. -DBUILD_EXAMPLES=ON
$ cmake --build .
...truncated...
$ examples/log
commit 8ac8c78c35905f7f9cc37f240c3d633a7cc5a5e3
Merge: 34ec6f3 4955125
Author: Edward Thomson <ethomson#edwardthomson.com>
Date: Mon Oct 9 15:15:08 2017 +0100
Merge pull request #4356 from pks-t/pks/static-clar
cmake: use static dependencies when building static libgit2
...truncated...
I'm trying to build an application via cmake 3.9.0. Cmake keeps complaining about the inability to find the tiff library: CMake error at CMakeModules/FindPackageHandleStandardArgs.cmake:51 (Message): Could not find REQUIRED package TIFF). I tried to install the library via sudo apt-get install libtiff5-dev but was still getting the same message. Then I checked-out the source code for libtiff 4 and built it from the source. Now I think we can hint the cmake with the location where to look for the libtiff via setting the variables TIFF_INCLUDE_DIR, TIFF_INCLUDE_DIRS, etc as described here: https://cmake.org/cmake/help/v3.6/module/FindTIFF.html. However I have failed in wiring the right values for the variables. Can somebody show me an example of sample libtiff instalation and the sample values for the configuration variable in order cmake would find the TIFF. Or is here another option how to show CMake where does the TIFF library lie?
cd build
cmake -DTIFF_INCLUDE_DIR=<dir> -DTIFF_LIBRARY=<filename> -GNinja ..
cmake --build .
Alternatively, you can modify the variables in your CMakeLists.txt before calling find_package():
set(TIFF_INCLUDE_DIR "<dir>")
set(TIFF_LIBRARY "<filename>")
find_package(TIFF)
add_executable(myexe TIFF::TIFF)
where <dir> is the include directory path and <filename> is the exact file path to the library.
Describe difference between these two command lines:
C:\xxxxx> cmake -help
Usage
$ cmake [options] <path-to-source>
$ cmake [options] <path-to-existing-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
The last description does not give me how to use the first, or the second.
Could you explain it to me?
When you use you do an in-tree build (cmake .), there is no difference.
When you do an out-of-tree build, there is a difference.
Suppose your project lives in ~/foo and your current directory is ~/foo/build
You have to run cmake .. for the first build. But for subsequent reconfigures, you can use cmake . because there is already a build there.
This command:
cmake [options] <path>
works as follows:
if <path> is not a valid (that is, already configured) CMake build directory, it is assumed to contain a CMakeList.txt. CMake will configure the current working directory as a build directory using <path>/CMakeLists.txt for source directory.
if <path> is a valid CMake build directory, the command reconfigures that directory using the source directory assigned when you first configured that build directory
So the common usage patterns are:
initial configuration:
mkdir my-build-dir
cd my-build-dir
cmake [options] my-source-dir
subsequent (re)configurations:
cmake [options] my-build-dir # current-work-dir is not important
alternative (initial) configuration using undocumented options:
cmake -Hmy-source-dir -Bmy-build-dir [options] # cwd is not important