I have a project that needs to be built like this:
./meson.py build
./ninja -C build install
This works well. The only thing is: the binaries are stored in (on Linux): /usr/local/bin. This would require me to input root password because the binaries are being written to a root-access folder, aka /usr/local/bin.
Is there a way to install the binaries in some folder in the /user/home directory, so that no passwords are required?
The thing is that everytime I debug and change something, the rebuilding process forces the binaries to be rewritten, which asks for password everytime.
This is what I tried:
Create a folder in home: mkdir ~/projectbin
Use ninja with --prefix option: ./ninja -C --prefix=~/projectbin install
This throws an error of unrecognized option --prefix.
I am new to ninja and meson, please let me know how to resolve this.
The way to pass an option to Meson is using the -D option. So to set the prefix, you should use meson -Dprefix=$HOME/projectbin build.
Note that you set this at configure time (ie when calling meson), not at build time (when calling ninja).
Related
What is exactly the command line (process and arguments) used by CLion when invoking CMake? I'm trying to use the same directory for manual builds using the terminal and for building using the IDE, but it seems that one is interacting badly with the other.
I have no problem with using CLion only to handle CMake configurations (to avoid slight configuration mismatch triggering another CMake execution), but it seems that even standard builds using make on the command line trigger cmake again.
I've seen that CLion prints it's "call" to CMake, but I don't see where it references the current working directory. And since on the GUI you configure paths relative to the project root folder (where CMakeLists.txt live), instead of relative to the build folder. I was hoping that this detail is the culprit here.
Usually in the command line I'd do it like this:
$ cd project
$ mkdir -p builds/debug
$ cd builds/debug
$ cmake $MY_CMAKE_OPTS -DSPECIAL_FILE=../../file.ext ../..
On CLion, though, I have to configure it like this:
CMake options: $MY_CMAKE_OPTS -DSPECIAL_FILE=file.ext
Generation path: builds/debug
The rest I've used the default
This special file is used on the configuration phase, so using paths other than relative to project root or absolute paths won't work.
Configuration step command line is shown in CMake view when you load/reload a CMake project: View - Tool Windows - CMake. The view has no default hotkey.
Example: /Users/vic/bin/cmake_ninja_wrapper.py -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - Unix Makefiles" /Users/user/src/helloworld.
Depending on configuration, the current directory can be PROJECT_SOURCE_DIR/cmake-build-debug (where the build files were generated for me), PROJECT_SOURCE_DIR/cmake-build-release, or other.
Build step command line is shown in Messages - Build view. It opens when you invoke build from Build menu. I don't think the current directory matters for it, as all the build files are already generated.
Example: /Applications/CLion.app/Contents/bin/cmake/mac/bin/cmake --build /Users/user/src/helloworld/cmake-build-debug --target helloworld -- -j 6
Then the view can be opened with Cmd-0 on Mac, or through menu: View -
Tool Windows - Messages.
To work with relative paths, you can refer to PROJECT_SOURCE_DIR variable in your CMakeLists.txt.
I have been working on LLVM, which uses CMake as a build system. I can create an out-of-source build as follows:
mkdir build
cd build
cmake ..
make
This works reasonably well when I am working on one branch, since Make can reuse build artifacts.
However, when I switch branches, a CMakeLists.txt file may have changed. To be sure I am running the corresponding binary of my current source-code, I run:
rm -rf build
mkdir build
cd build
cmake ..
make
This is inefficient, because I loose all build artifacts. Ideally, CMake would only rebuild what has changed.
How can I achieve incremental builds using CMake whilst switching branches and also be guaranteed build correctness?
This is how I use it and I am happy with it (for simplicity assume that I have 1 CMakeLists.txt) in entire repo:
/
/src
/src/repo1 (on branch1)
/build
/build/repo1_branch1
/build/repo1_branch2
so when I want to generate cmake files from branch1
cd /src/repo1
git checkout branch1
cd /build/repo1_branch1
cmake /src/repo1
for the other branch I'd simple replace two middle lines...
In addition you can make more folders for Release and Debug configurations etc.
I realize that this way is not ideal but it's clear consistent and could be automatized. So script would get repo name (root folder name), branch name, create a folder in fixed location with name repo_name+branch_name (like /build, or ok /home/user/builds) go there and run cmake.
I just download poppler to Linux system,and I want to incorporate it in my app to parse pdf file.
(My goal is to convert pdf file to plain text.)
How can I do this?
Poppler's git tree includes a useless INSTALL doc that just tells you to run ./configure, but they don't include automake/autoconf auto-generated files (including configure) in git. (Probably they do include them in tarball source releases.)
I just built poppler from git source (on Ubuntu 15.04) like so:
git clone --depth 50 --no-single-branch git://git.freedesktop.org/git/poppler/poppler
cmake -G 'Unix Makefiles' # other -G options are to generate project files for various IDEs
# look at the output. If it didn't find some libraries,
# install them with your package manager and re-run cmake
make -j4
# optionally:
sudo make install
It appears that they maintain an autoconf/automake build setup, so you can use that OR cmake to create a Makefile.
If you just want to see if the latest git poppler works better than the distro package, you don't need to sudo make install, you can just run utils/pdftotext or whatever right from the source directory. It apparently tells the linker to embed the build path into the binary, as a library search path, so running /usr/local/src/poppler/utils/pdftotext works, and finds /usr/local/src/poppler/libpoppler.so.52.
If the latest poppler does work better than the distro-packaged poppler, you should install it to /usr/local/bin with sudo make install. When you upgrade to the next version of your distro, check your /usr/local. Often the new distro version will be newer than when you built it from source, so you should just remove your version from /usr/local/{bin,share,lib,man,include}. (Or make uninstall in the source dir, if supported).
Their website explains it very clearly :
Poppler is available from git. To clone the repository use the following command:
git clone git://git.freedesktop.org/git/poppler/poppler
Once you download the source code, read the INSTALL file where it says :
cd to the directory containing the package's source code and type
./configure to configure the package for your system.
Type `make' to compile the package.
Type `make install' to install the programs and any data files and
documentation.
Since some time has passed and it seems there was some uncertainty, I also took a look.
At the end of 2021, their homepage says
We run continuous integration via the gitlab CI
I checked out their .gitlab-ci.yml which has many build tasks. It would seem these days we build libpoppler like this:
git clone git://git.freedesktop.org/git/poppler/test test.repo
mkdir -p build && cd build
cmake -DTESTDATADIR=`pwd`/../test.repo -G Ninja ..
ninja
I am trying to use CMake in order to compile opencv.
I am reading the tutorial but can't understand what is CMakeLists files and how is it connected to the gui of CMake?
Also couldn't understand what are makefiles, are they the same is CMakeLists?
And which file is it which I in the end open with visual-studio?
I don't know about Windows (never used it), but on a Linux system you just have to create a build directory (in the top source directory)
mkdir build-dir
go inside it
cd build-dir
then run cmake and point to the parent directory
cmake ..
and finally run make
make
Notice that make and cmake are different programs. cmake is a Makefile generator, and the make utility is governed by a Makefile textual file. See cmake & make wikipedia pages.
NB: On Windows, cmake might operate so could need to be used differently. You'll need to read the documentation (like I did for Linux)
CMake takes a CMakeList file, and outputs it to a platform-specific build format, e.g. a Makefile, Visual Studio, etc.
You run CMake on the CMakeList first. If you're on Visual Studio, you can then load the output project/solution.
Yes, cmake and make are different programs. cmake is (on Linux) a Makefile generator (and Makefile-s are the files driving the make utility). There are other Makefile generators (in particular configure and autoconf etc...). And you can find other build automation programs (e.g. ninja).
CMake (Cross platform make) is a build system generator. It doesn't build your source, instead, generates what a build system needs: the build scripts. Doing so you don't need to write or maintain platform specific build files. CMake uses relatively high level CMake language which usually written in CMakeLists.txt files. Your general workflow when consuming third party libraries usually boils down the following commands:
cmake -S thelibrary -B build
cmake --build build
cmake --install build
The first line known as configuration step, this generates the build files on your system. -S(ource) is the library source, and -B(uild) folder. CMake falls back to generate build according to your system. it will be MSBuild on Windows, GNU Makefiles on Linux. You can specify the build using -G(enerator) paramater, like:
cmake -G Ninja -S libSource -B build
end of the this step, generates build scripts, like Makefile, *.sln files etc. on build directory.
The second line invokes the actual build command, it's like invoking make on the build folder.
The third line install the library. If you're on Windows, you can quickly open generated project by, cmake --open build.
Now you can use the installed library on your project with configured by CMake, writing your own CMakeLists.txt file. To do so, you'll need to create a your target and find the package you installed using find_package command, which will export the library target names, and link them against your own target.
Cmake from Windows terminal:
mkdir build
cd build/
cmake ..
cmake --build . --config Release
./Release/main.exe
Regarding CMake 3.13.3, platform Windows, and IDE Visual Studio 2017, I suggest this guide. In brief I suggest:
1. Download cmake > unzip it > execute it.
2. As example download GLFW > unzip it > create inside folder Build.
3. In cmake Browse "Source" > Browse "Build" > Configure and Generate.
4. In Visual Studio 2017 Build your Solution.
5. Get the binaries.
Regards.
I got a C project to compile and run in Linux. It is a very big project with many subdirectories. Inside the parent directory there are files Makefile.am and Makefile.in.
I tried running make -f Makefile.am, and got the following error:
make: Nothing to be done for `Makefile.am'.
What does it mean? How do I accomplish my task?
These files are used with the Autotools suite. Makefile.am files are compiled to Makefiles using automake.
Have a look to see if there is a configure script in the directory. If there is, then type:
./configure
If not, then run:
autoreconf
in the directory, which should create the configure script (you will need to have the Autotools suite installed to run this).
After that, you should have a configure script that you can run.
After the configure is complete, you should have a normal Makefile in the directory, and will be able to run
make
What has been left out:
Makefile.am are transformed to Makefile.in using automake.
Makefile.in are transformed to Makefile by running configure.
Neither of these (Makefile.{am,in}) are supposed to be used with make -f.
If the tarball already ships with configure, just run that and make. If it does not, run ./autogen.sh or bootstrap(*). If that does not exist, use autoreconf instead.
(*) autogen/bootstrap: A convenience script added by developers that should just call autoreconf. Unfortunately there are some people that eschew autoreconf and unnecessarily call all the lowlevel commands themselves.
To supplement what has already been said:
Search for a script called configure in the project directory. If it is there, building the project will be:
./configure
make
and optionally, to install:
sudo make install
or su -c "make install"
Even if there is no configure script. there might be one autogen.sh. Run this script to generate the configure script and do as above.
Makefile.am is probably to be used with automake.
try:
automake
you might also just want to try
make -f Makefile.in
Since this is the product of running automake