JetBrains has spoiled me. I'm familiar with the standard UNIX make file and the make, make install routine normally associated with installing software with traditional make files, but I'm not as familiar with cmake since CLion does it all for me.
I want to distribute my code to others and provide simple instructions for building it via cmake so that they have a binary they can execute. The official cmake tutorial shows writing install rules in the CMakeLists.txt file but it isn't clear if this is supported by CLion (or even if it needs to be).
For a simple, single-file (main.cpp) application, what would be an example of how to build it using cmake (assuming those it is distributed to don't have CLion nor use another IDE, they just want to build and use it)?
To build code that comes with a CMakeLists.txt file, you run cmake to generate a Makefile (or other build configuration file):
cmake <path_to_CMakeLists.txt>
Then you run
make;make install
as usual. (or as described in the comment, you can type cmake --build . instead of make - useful if you're on a platform with a different build system)
You don't want to check in the Makefile into your source control, though, as it needs to be generated on the computer that will actually be doing the building.
Related
I'm currently learning C++ and I'm working on a small project. I was wondering how I can generate an executable of my project. I'm not sure how to do it, I'm using Ubuntu 20.04
I've googled it but I can not find any instructions on how to do it.
Well. If you are using CLion, you can just create a new project, and check the CMake file that CLion generate. Something like this:
cmake_minimum_required(VERSION 3.20)
project(Test)
set(CMAKE_CXX_STANDARD 14)
add_executable(Test main.cpp)
And in that file there was a line with a function called add_executable, in that function you set first the exe name and then the source files. And just run the project in CLion. By default CLion create a directory calle "cmake-build-debug" where the exe file are located.
If you want to add more libraries, change the binaries source directory and more. You will need learn CMake. Also you can use CMake standalone whiteout CLion, you just need install it sudo apt-get install cmake and use then in the terminal.
Expanding over #Steback's answer:
First, a clarification: an executable file is a file that can be executed by the system. It (roughly) contains assembly commands. Under Windows executable files are marked with an .exe extension. Under linux, they are usually extension-less.
To generate an executable file from C / C++ code you ("only") need a C/C++ compiler. A default / pre-installed one on Ubuntu is gcc / g++ (whereas on Windows you need to actively install one).
CLion is an IDE and (exactly like any other IDE) can run the compiler for you. IDE (stands for Integrated Development Environment) is a program which incorporates (minimally) a text/code editor, a compiler and a debugger (all of which it invokes normally via command line, just as you can do yourself).
CLion is an advanced (and excellent) IDE. In CLion, the way you specify how exactly it should invoke the compiler is via the CMake language (not to be confused with the unix tool make which chiefly only knows to run commands conditionally on file modified date).
CMake code should be placed in a file named CMakeLists.txt in the project root directory (sometimes CLion creates this file for you automatically). A minimal cmake project looks like
# Specify cmake language version to use for this file
cmake_minimum_required(VERSION 3.10)
# Specify any name for the project
project(NameYourProject)
# A name for your executable file and the code files needed to build it
add_executable(YourExecutableName source_file1.cpp somefolder/source_file2.cpp header_file.h)
Of course this is just a very minimal example. The CMake language is a powerful language to specify build processes, with cross-platform support. You can look it up / learn it someday.
When giving the "build" command to CLion it will now do two things:
use the cmake tool to generate a set of commands for gcc/g++ (this is called "cmake configure" + "cmake generate") - according to what you wrote in CMakeLists.txt
run the generated commands to hopefully build your executable.
As a beginner, you may be better off first trying to run the compiler yourself via the command line to see what it does. You can also opt for a different IDE (e.g. CodeBlocks, eclipse, Dev C++) where you specify what you need the compiler to do via a GUI and not via CMake (although CMake is arguably more convenient).
I'm using Dev C++. When I run and compile it, it automaticcally generate a .exe file. Just install it and open ur file with it and compile it. Should work good.
I would like to automate the build of CMake using an MSVC C++ script instead of using CMake-gui to generate the build or CMake terminal or using the CMake integrated on MSVC 2017 by right click on the CMakeLists.txt to build it manually. Assume we have a project (name it: initialize) that includes the CMakeLists.txt and initialize.cpp, so my question is how I can convert these commands into a C++ code, assume build_initialize.cpp:
mkdir build
cd build/
cmake ..
So, the requirement of this tiny C++ code is to
Set the path to this project
Create build folder
Run CMake
At the end if I execute build_initialize.exe, the job is just to build the initialize.cpp using CMake. The goal is to test if the build is success or not as a test case within another project that has several test cases.
You may ask, why I didnot include it to the top CMakelists.txt, and then build it from the beginning using CMake. If I am going to do that, I will get an executable file. As a result, by running the ctest of CMake, the initialize.exe will require a pace of hardware. This is not the goal. My goal is just to build it. If I run build_initialize.exe, just repeat the build using CMake without initialize.exe execution.
Sorry, it could be very simple, but I lack the good experience either in C++ or CMake. Two days have been lost without success.
Thanks to all of you for the comments. The answer has been given by #Fred. To run cmake from C++ script, simply the system() can be used such as: System(cmake -S path_to_src -B path_to_bld).
Useful link: https://faq.cprogramming.com/cgi-bin/smartfaq.cgi?id=1043284392&answer=1044654269
I'm trying to create an Open Source C++ project. I want it to be as easy to build as possible, but at the same time cross platform.
I don't need gui or heavy libraries like boost or Qt, so I've settled on using GitHub, CMake, and LibSourcey.
My problem is, I can't find a way to make my project easy to build in windows, which is my development environment.
How can I "make install" a library in Windows for use in my project? Do I even have to install it in windows?
Is it possible to download, build, and link it automatically?
On windows, besides an installer, I also want to make a portable version, so don't want any hard coded library paths.
I assume, on some platforms, like Linux, libraries are built separably and packaged up by maintainers. So I shouldn't just bundle up my own copies.
So, my question is:
How can I set up a project that is cross platform and easy to build, and what are the best practices?
You can create git submodule in your git repo with path for example
contrib/LibSourcery and url to github repo of LibSourcery, because of LibSourcery uses cmake you just
need add such line into your CMakeLists.txt: add_subdirectory(contrib/LibSourcery)
So person who want to use your code, just do git clone --recursive url
to get all of your code and dependencies, after that it run cmake -G, to create project for IDE of his choice (including MSVC++ of course),
open project in IDE and press build button, that's all.
Use babun. It's a wrapper for cygwin and it works perfectly for everything I need, even compiling with cmake.
Alternatively, you could use premake, which uses lua as a config system and works fine on windows.
There is no elegant cross-platform way, since the idea of "make install" doesn't exist on Windows, therefore the use of cmake install is undefined there. For something which is supposed to help cross-platform, I feel this is a deficiency w cmake.
My solution is to write a custom _INSTALL which takes the same args as cmake install and then on Linux it just calls install, and on Windows it does an add_command which does a post-build copy to the install paths, which accomplishes the same thing. Basically, _INSTALL behaves the way you expect a cross-platform install command to behave. Can share my _INSTALL func if there is interest.
_INSTALL is placed nto a Helper.cmake, and included in all my CMakeList.txt for my projects, so all I need to do is call it and the generated lib/inc files magically appear for both win and linux.
You can use vcpkg, an open source package manager for c and c++. It allows to easily download and compile libraries and then use find_package from within CMake like you would on linux. It's very easy to use. It even provides hints as to how to alter your cmake file to use the libraries.
I started by installing packages with the command line, and then wondered why they wouldn't show up in visual studio. But I realized that it would download 32 bit libraries by default. Use .\vcpkg install <libname>:x64-windows if you need the 64 bit libraries.
After running the integrate command, you will need to delete any cmake caches to have MSVS use the new toolchain.
I understand that CMake enables a project to be easily built in a variety of compiler/IDE environments. I have experienced this for myself and was amazed when CMake produced a working, buildable Xcode project for me from some open source project (cool!)
But what I don't understand is how you properly update the CMake system after you have made significant changes to the project that CMake created for you.
For example I am envisioning a workflow in which the project should be kept portable via CMake. So I create a clone of a github project, use CMake to create my XCode project, and then go to work implementing some new feature or bug fix. Perhaps these changes are non-trivial and affect build.
After these changes are complete I want to push the code base back to github. What happens now? Must all of the CMake files be updated by hand to reflect all of the work that I've done? Or is there some equally magical feature to update the CMake files with the changes that were implemented in XCode (or Visual Studio, or some other supported IDE/compiler combo)?
What is the general "Roundtrip" workflow with CMake and how efficient is it?
The point is that you change your project by changing the CMake configuration files themselves. It could be that you'll find some other tool which manages cmake projects, which will make changes to your cmake files. In the example you mention, you have to check if XCode is modifying your cmake files.
You have to commit all the necessary modifications you do to your cmake files, and your build program (make, ninja, or any other) will run cmake every time the cmake project files are touched.
Advanced note: if you use the command file with globbing instructions to get the list of your sources files, you might be interested to read Getting cmake to run before building after pulling from git
I am new in Ubuntu/Linux and I've been working with java using the NetBeans IDE, so I don't have much experience with building c++ projects. But now I have to provide a proof of concept and I need to connect a C++ client with my ActiveMQ server. I downloaded The ActiveMQ-CPP API from this link, but I can't build/run it.
The download came with the files: Maklefile.am and Makefile.in. I searched it and I found that I need automake/autoconf to build it. I tried running ./configure but it says that it couldn't find such file or directory. I tried
sudo apt-get update
sudo apt-get install automake
sudo apt-get install autoconf
and a lot of other commands that I found on the Internet. None of then worked. I know that this question is really basic and it seems to be already answered somewhere else, but every attempt I've made failed. I think I'm missing something. I even tried the solution provided in the last message in this topic but it didn't work either.
Can anyone help me install autoconf/automake, or tell me how to use Makefile.am / Makefile.in to build the project I downloaded, or even suggest me some other way of building it?
Since you're open to other methods of building your project, I'm going to suggest CMake. It is a far better build system than autotools (at least from where I stand).
#CMakeLists.txt
project(MyProject CXX)
set_minimum_required(VERSION 2.8)
add_executable(foobar foo.cpp bar.cpp)
That example will build an executable called "foobar" by compiling and linking foo.cpp and bar.cpp. Put the above code in a file called CMakeLists.txt, then run the following commands:
cmake <path to project> #run in the folder you want to build in
make #this does the actual work
The really cool thing about CMake is that it generates a build system (Makefiles by default) but you can use it to generate project files for Eclipse, a Visual Studio solution, and a bunch of other things. If you want more information, I'd check out their documentation.
The "configure" script should be in your ActiveMQ-cpp source directory. From the Linux command line, you should be able to:
1) "cd" into your ActiveMQ* directory
2) "ls -l" to see the "configure" script
3) "./configure" to set things up for building the library\
4) "make" to actually build the library
This is mentioned in comments, but this particular point of confusion has been common for well over a decade and I think needs to be clarified as often as possible. You DO NOT need to have autoconf or automake installed to build a project that used those tools. The entire point of the autotools is to generate a build system that will build on a system using only the standard tools (make, a c compiler, sh, and few others.) Unfortunately, many developers release tarballs that do not build cleanly. If you unpack the tarball and it does not contain a configure script, or if the configure script is broken, that is a bug in the package. The solution is absolutely not to install autoconf/automake/libtool and try to produce a working configure script. The solution is to report the build error as a bug to the package maintainer.
The world would be a better place if Linux distributions stopped installing multiple versions of the autotools by default as less than .002% of the population needs those tools, and anyone who actually needs to have the tools should be capable of installing it themselves. Anyone incapable of acquiring and installing the tools has no business using them.