I read the documentation.
It says:
A CMake Generator is responsible for writing the input files for a native build system.
What exactly does that mean?
If I have a set of C++ files in my project, are these the input files?
If I'm using Linux, what is my native build system by default? Make?
Why do the input files have to be written by the generator if they already exist?
What's a generator?
To understand what a generator is, we need to first look at what is a build system. CMake doesn't compile or link any source files. It used a generator to create configuration files for a build system. The build system uses those files to compile and link source code files.
So what's a build system?
A build system is a broad term that groups together a set of tools used to generally compile and link source code, but it can also include auxiliary tools used during a build process.
For example, in a multi-stage build system, one executable might be built to be used in the build process of another build.
Depending on the tool chain used on a system, CMake will generate multiple files and folders to allow the building of the source files referenced in the CMakeLists.txt and supporting .cmake files.
Sometimes multiple build systems may be installed on a computer, like for Windows you could have a Visual Studio and MinGW build system. CMake allows you to specify which if these build systems to generate configuration files for.
CMake includes a number of Command-Line, IDE, and Extra generators.
Command-Line Build Tool Generators
These generators are for command-line build tools, like Make and Ninja. The chosen tool chain must be configured prior to generating the build system with CMake.
The following are supported(**):
Makefile Generators
Borland Makefiles
MSYS Makefiles
MinGW Makefiles
NMake Makefiles
NMake Makefiles JOM
Unix Makefiles
Watcom WMake
Ninja Generators
Ninja
Ninja Multi-Config
IDE Build Tool Generators
These generators are for Integrated Development Environments that include their own compiler. Examples are Visual Studio and Xcode which include a compiler natively.
The following are supported(**):
Visual Studio 6
Visual Studio 7
Visual Studio 7 .NET 2003
Visual Studio 8 2005
Visual Studio 9 2008
Visual Studio 10 2010
Visual Studio 11 2012
Visual Studio 12 2013
Visual Studio 14 2015
Visual Studio 15 2017
Visual Studio 16 2019
Visual Studio 17 2022
Green Hills MULTI
Xcode
Extra Generators
These are generators that create a configuration to work with an alternative IDE tool and must be included with either an IDE or Command-Line generator.
The following are supported(**):
CodeBlocks
CodeLite
Eclipse CDT4
KDevelop3 (Unsupported after v3.10.3)
Kate
Sublime Text 2
If I have a set of C++ files in my project, are these the input files?
Yes, they are some of the input files. For a make build system you also have a MakeFile. For Visual Studio you have a solution file (.sln). With both systems there are additional files needed that CMake knows how to create given a proper CMakeLists.txt file.
If I'm using Linux, what is my native build system by default? Make?
Generally, yes, but other build systems could be setup like Ninja.
Why do the input files have to be written by the generator if they already exist?
Some source files may already exist, but CMake has the ability to generate header and source files. Also as mentioned above, there are configuration files that must be generated that depend on the source files supplied in the CMakeLists.txt file.
** According to the documentation for CMake Version 3.9 & 3.15 & 3.25
Maybe a picture is worth a thousand words.
A CMake Generator is responsible for writing the input files for a
native build system.
means that CMake prepares build scripts for a native build system when no generator is specified. In Linux the default build system is Make and its input file are makefiles, which are then interpreted and a build is executed accordingly. Before the first execution of CMake build scripts do not exist.
C++ source files (or any other source files) are not input files to a build system. Build system scripts specify how to handle source file in order to produce binary executables.
As far as I know, the standard native build system in Unix is GNU Make (gmake) known as "make".
The Google guys/gals also released a different tool called Ninja.
Related
I'm just starting in the world of C++. I was kind of forced into this because I want to study a Physics simulation. With a lot of effort, I found out that I needed to install Microsoft Visual Studio on my computer in order to edit and compile the source files that are available on GitHub.
However I noticed that some of the authors on GitHub do not include .sln files in their projects, and then I'm unable to open/edit/compile them with Microsoft Visual Studio. Conversely, those projects containing an .sln file and that are meant to run on DirectX are the ones that I was able to compile/execute after making my own modifications.
So... What is lacking in those projects that do not contain an .sln file or that are not meant for DirectX?
There are numerous build systems in the world, but for the Windows ecosystem there are a few dominate ones.
MSBuild (Microsoft Build) is the default build system for Visual Studio. .vcxproj files are the Visual C++ project files that use MSBuild, and the .sln files are meta-files that organize one or more .vcxproj files (or .csproj files for C#).
NMake (Microsoft Program Maintenance Utility) is the older 'makefile' build system from Microsoft. It's still around, but has not been updated in many years. Visual Studio can also support nmake-based .sln/.vcxproj files, but this has fallen out of favor over time and is all-in-all fairly clunky.
MinGW (Minimalist GNU for Windows) has its own 'makefile' build system.
CMake is a cross-platform 'meta-make' solution that is used by many platforms including Windows. It can target MSBuild, Ninja, MinGW Makefiles, etc. and a number of other build-systems which is why it's a popular open source and multi-platform solution. Visual Studio and Visual Code both support building with this build system, and you can of course use it from the command-line directly if you want. The presence of a CMakeList.txt file indicates this.
To provide some of the functionality of a '.sln' file for CMake, CMake 3.20 or later supports a CMakePresets.json file which makes it much easier to use within the Visual Studio and Visual Code IDEs.
See Microsoft Docs for more in Visual Studio build. For more on CMake with Visual Studio, see this article.
For general background on 'makefiles', see Wikipedia.
My list above is far from complete as there are numerous build systems out there (SharpMake, Meson, FASTbuild, etc.). For a good overview, see this blog post.
Microsoft uses .sln files as a way for Visual Studio to manage projects (files, compilation rules, dependencies, etc.), so it is Microsoft-specific.
Most of C++ projects are not written using Visual Studio however, but use other editors & build systems. Projects that do not have a .sln file, could have CMakeLists.txt files that can be compiled with CMake (which Visual Studio got support for in recent version), or meson.build files to be compiled with meson, Makefile for make, you get the point.
There are a lot of build systems & IDEs for C++ because it existed for very long time, and because it is a very popular language (for a good reason) so people created tools that suit their workflow. However, there should not be any differences in code you write (given it conforms to a standard version of C++) regardless of the build system or IDE you choose to use.
I have a project which i have generated with cmake and running in visual studio 2010.I changed the configuration to x64,in visual studio my active solution and the Target Machine in(Properties->Linker->Advanced) is set as x64.I still get the linker LNK1112 error.Is this something which i set in cmakelist.txt if so what is the command?
-swetha
It's not something you'd want to set in CMakeLists.txt. Basically, CMake has multiple generators for different compilers. (The x86 and x64 compilers are two distinct compilers on Windows.) When you generate the build files, you need to pass along the correct compiler for CMake to use, or if you use the GUI, select Win64. From the command line:
cmake -G "Visual Studio 14 Win64" path/to/your/CMakeLists.txt
or whatever version of Visual Studio you want. You can see the available generators with:
cmake --help
If this didn't solve your problem, try it again after deleting the generated build files.
If that still doesn't solve the issue, you are linking to a third party dependency built for x86.
Try to delete all *.obj files in your solution and let compiler compile all files again. This problem may cause of compiler try to reference obj files that was compiled x64
I would like to generate visual studio project files on linux using cmake.
Unfortunately, the visual studio project file generator is not enabled by default on linux.
The cmake build instructions don't mention how to enable this feature on linux. It seems like the generators are enabled based on the host platform cmake is being build. Has anybody a patched cmake to enable the Visual Studio Project Generator on linux ?
We have tools that work on linux and windows for analyzing projects by parsing .sln/.vcxproj files. However generating .sln/.vcxproj files on windows is quite inconvenient as our main development is done on linux/osx.
You cannot generate Visual Studio Solutions under Linux. Nowadays you can generate Visual Studio solutions via ssh to a Windows docker container.
I'm trying to build binary files of the LAPACK 3.7.0 using CMAKE based on what is told here. In order to use them in my Visual Studio 2013 C++ project.
But I really don't know which option should I choose here?
And also which compilers should I choose in the following?
Because I can't find them in the suggested directories within Program Files or Program File(x86) folders.
my machine uses a dual-core Intel(R) Core(TM) 2 Duo CPU
When using Visual Studio < 2015, a common solution is to run CMake GUI from Visual Studio Command line.
Use windows start menu to run "Visual Studio Command Prompt"
Run cmake-gui from command line. If the folder is in your path, simply launch cmake-gui. If not, launch it using the full path
Locate the source folder of your project (the folder containing the top-level CMakeLists.txt) and create a new build folder (ex c:/my-project/build_32). Generating an environment in the source folder is discouraged)
Generate your project selecting the right MSVC version. In your case, it will be "Visual Studio 12 2013". In my case, this is MSVC 2010.
That's all. Click on finish button and it should generate the compilation environment, solutions, projetcs, etc.
This will generate environment for compiling x86 application. If you also need to compile a x64 version of your project, simply follow again that process, generating in a new build folder and selection "Visual Studio 12 2013 Win64".
By default, if you have a paid version of Visual Studio you have both x86 and Win64 compiler installed. If you have the express version, you only have the x86 compiler (so generation using MSVC Win64 will fail).
I tried compiling the POCO library on my Windows 7 computer. Though I use eclipse cdt, it said that It could only be compiled with Visual C++:
Microsoft Visual Studio 7.1 (2003), 8.0 (2005), 9.0 (2008) or 10.0
(2010) is required to build the POCO C++ Libraries on Windows
platforms. Solution and project files for all versions are included.
For Visual Studio 2008 and 2010, 64-bit (x64) builds are supported as
well. You can either build from within Visual Studio (Build->Batch
Build->Select All;Rebuild) or from the command line. To build from the
command line, start the Visual Studio .NET 2003/2005/2008/2010 Command
Prompt and go (cd) to the directory where you have extracted the POCO
C++ Libraries sources. Then, simply start the buildwin.cmd script and
pass as argument the version of visual studio (71, 80, 90 or 100). You
can customize what is being built by buildwin.cmd by passing
appropriate command line arguments to it. Call buildwin.cmd without
arguments to see what is available. To disable certain components
(e.g., NetSSL_OpenSSL or Data/MySQL) from the build, edit the text
file named components in the distribution root directory and remove
the respective lines. Certain libraries, like NetSSL_OpenSSL, Crypto
or Data/MySQL have dependencies to other libraries. Since the build
script does not know where to find the necessary header files and
import libraries, you have to either add the header file paths to the
INCLUDE environment variable and the library path to the LIB
environment variable, or you'll have to edit the buildwin.cmd script,
where these environment variables can be set as well. In order to run
the test suite and the samples, the top-most bin directory containing
the resulting shared libraries must be in the PATH environment
variable.
I downloaded visual c++ express, but when I run the "buildwin.cmd" I get these errors:
devenv is not recognized as an internal or external command.
I also can't find any "build" menue inside the program. Is the full Visual C++ required to build the library? If so, is there any cheaper option?