parent
2627864383
commit
e2722d2c09
@ -0,0 +1,77 @@
|
||||
---
|
||||
layout: page
|
||||
# TODO: rename to 'Basics'?
|
||||
title: Concepts
|
||||
nav_order: 2
|
||||
---
|
||||
|
||||
# Concepts (TODO: rename to "Basics" or "Basic Concepts"?)
|
||||
|
||||
To effectively use cmkr it helps to understand the basic concepts of CMake.
|
||||
|
||||
## Projects
|
||||
|
||||
A CMake **project** is a collection of targets. In the context of libraries the project usually corresponds to the **package** that other projects can depend on.
|
||||
|
||||
<sub>Visual Studio: a CMake **project** corresponds to a _solution_.</sub>
|
||||
|
||||
## Targets
|
||||
|
||||
The basic unit of CMake is called a **target**. A target (also referred to as [binary target](https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#binary-targets) in the CMake documentation) corresponds to an executable or library you can build. There are also [pseudo targets](https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#pseudo-targets), but we ignore them for now.
|
||||
|
||||
<sub>Visual Studio: a **target** corresponds to a _project_.</sub>
|
||||
|
||||
## Target Properties
|
||||
|
||||
Targets have a collection of **properties** that describe how to build them.
|
||||
|
||||
Examples of properties:
|
||||
|
||||
- _Sources_: the `*.cpp` files used to build the target.
|
||||
- _Compile options_: Command line flags for the compiler.
|
||||
- _Link libraries_: The **dependencies** required to build this target.
|
||||
|
||||
<sub>See the [CMake documentation](https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-targets) for an exhaustive list of target properties.</sub>
|
||||
|
||||
**Important**: The term **link** has a slightly different meaning in CMake than you might expect. In addition to adding a library to the command line of the linker, CMake also propagates properties of the target you link to.
|
||||
|
||||
<sub>You can think of **linking** as _depending on_.</sub>
|
||||
|
||||
The propagation of properties depends on their **visibility**:
|
||||
|
||||
- **Private**: properties that are only used when building the target itself.
|
||||
- **Interface**: properties that are used when depending on this target.
|
||||
- **Public**: combination of private and interface.
|
||||
|
||||
In practice you default to **private**, unless consumers of your library _require_ the property to build their target. In that case you use **public**.
|
||||
|
||||
### Example
|
||||
|
||||
The most intuitive example is with _include directories_. Imagine there are two targets:
|
||||
|
||||
1. `StringUtils`: A library with string utilities.
|
||||
- _Sources_: `StringUtils/src/stringutils.cpp`
|
||||
- _Include directories_: `StringUtils/include`
|
||||
2. `DataProcessor`: An executable that uses functionality from `StringUtils` to process some data.
|
||||
- _Sources_: `DataProcessor/src/main.cpp`
|
||||
- _Link libraries_: `StringUtils`
|
||||
|
||||
The _include directories_ property of `StringUtils` has to be **public**. If it was **private**, the `DataProcessor` target would fail to `#include <stringutils.hpp>` since the _include directories_ property is not propagated.
|
||||
|
||||
The `cmake.toml` for this example would look something like this:
|
||||
|
||||
```toml
|
||||
[project]
|
||||
name = "DataProcessor"
|
||||
|
||||
[target.StringUtils]
|
||||
type = "static"
|
||||
sources = ["StringUtils/src/stringutils.cpp"]
|
||||
headers = ["StringUtils/include/stringutils.hpp"]
|
||||
include-directories = ["StringUtils/include"]
|
||||
|
||||
[target.DataProcessor]
|
||||
type = "executable"
|
||||
sources = ["DataProcessor/src/main.cpp"]
|
||||
link-libraries = ["StringUtils"]
|
||||
```
|
||||
@ -0,0 +1,82 @@
|
||||
---
|
||||
layout: page
|
||||
title: Philosophy
|
||||
nav_order: 3
|
||||
---
|
||||
|
||||
# Philosophy
|
||||
|
||||
## Problem statement
|
||||
|
||||
Similar to writing good C++, writing good CMake is difficult. The main difference is that nobody actually wants to learn CMake. The build system is something that should "just work".
|
||||
|
||||
There have been many attempts at creating new build systems (with varying levels of success). Naturally this causes [competing standards](https://xkcd.com/927/), which is undesirable. CMake is pretty much the de facto standard, and it has seen extensive use in complex software projects.
|
||||
|
||||
One of the main issues of CMake is the turing-complete scripting language you use to describe your projects. As your project gets more complex this can be very helpful, but it also unnecessarily complicates simple projects. There have been discussions about a declarative language on the [CMake issue tracker](https://gitlab.kitware.com/cmake/cmake/-/issues/19891) to solve this problem, but it looks like a "LISP-like" language is seriously being considered...
|
||||
|
||||
## The solution
|
||||
|
||||
The way cmkr (pronounced "cmaker") solves this problem is by using [TOML](https://toml.io/). Below is a minimal `cmake.toml` project:
|
||||
|
||||
```toml
|
||||
[project]
|
||||
name = "cmkr_for_beginners"
|
||||
|
||||
[target.hello_world]
|
||||
type = "executable"
|
||||
sources = ["src/main.cpp"]
|
||||
```
|
||||
|
||||
The key difference between `cmkr` and other build systems is that it _generates_ CMake. This means that your projects are fully compatible with the CMake ecosystem, and you can try it out without having to rewrite your whole build system.
|
||||
|
||||
TODO: link/include more examples? Talk about conditions, packaging (missing)
|
||||
|
||||
### Another layer?!
|
||||
|
||||
A common issue people have with cmkr is that it introduces an additional layer of indirection to your build system. CMake is already a meta-buildsystem, which means you could call cmkr a "meta-meta-buildsystem".
|
||||
|
||||
Presumably the reason for this friction is that additional layers of abstraction introduce additional complexity. Because of this cmkr has been designed to be completely seamless:
|
||||
|
||||
- The user doesn't have to install any additional software to use cmkr. All you need is a semi-recent version of CMake and a C++ compiler.
|
||||
- Modifying `cmake.toml` automatically triggers a regeneration of `CMakeLists.txt`. There is no change to your build process.
|
||||
- The `CMakeLists.txt` is generated to be human-readable. This means you can easily "eject" from cmkr and go back to CMake.
|
||||
|
||||
An additional argument for cmkr is that anecdotally people say it "just works". Because of its simplicity it's also easy to teach, even to people without programming experience.
|
||||
|
||||
There is also precedent in the JavaScript community. Bundlers and translators are the norm there and their developer experience is miles ahead of C++.
|
||||
|
||||
<sub>Not to say the JavaScript ecosystem is without its flaws, but generators does not appear to be one of them</sub>
|
||||
|
||||
### Unsupported features
|
||||
|
||||
Because cmkr is still in early in development there are many missing/unfinished features. It was decided that users can bridge the gap by including CMake at arbitrary locations.
|
||||
|
||||
This has the advantage that it forces complexity in the build system to be self-contained and modular, a problem all too common in projects as they age.
|
||||
|
||||
## Enterprise
|
||||
|
||||
Words like "bootstrapping" and "generating code" might worry engineers working in an enterprise environment, and rightly so. From the beginning it has been a priority to make cmkr suitable for use in big corporations with strict protocols for security and reproducibility.
|
||||
|
||||
### No additional dependencies
|
||||
|
||||
As mentioned above, the only thing you need is a working C++ compiler and a semi-recent version of CMake. It is assumed that you are already building (and executing) C++ projects on your servers, so cmkr does not introduce additional requirements.
|
||||
|
||||
All the logic for downloading and compiling the `cmkr` executable is self-contained in a ~250 line `cmkr.cmake` script. You can easily audit it and see if it's up to your standards.
|
||||
|
||||
### Reproducibility
|
||||
|
||||
Per default the `cmkr.cmake` bootstrapping script contains the exact version of cmkr used to generate your project. As long as the cmkr repository is available you will build the exact same version of cmkr, which will generate the exact same `CMakeLists.txt` file.
|
||||
|
||||
This also means that cmkr can decide to break backwards compatibility without affecting legacy projects. An effort will always be made to maintain backwards compatibility though.
|
||||
|
||||
### Integrity
|
||||
|
||||
As an additional safeguard you can modify `cmkr.cmake` to pin the version tag to a commit hash. This hash is checked to ensure the integrity of the upstream repository.
|
||||
|
||||
### Availability
|
||||
|
||||
You can easily point `cmkr.cmake` to a mirror of the cmkr repository to ensure availability should something catastrophic happen.
|
||||
|
||||
### Not executed in CI
|
||||
|
||||
The final (and key) feature is that the bootstrapping process is never executed in CI environments. This means `cmkr` is only ever executed on your developer's machines and not on your infrastructure.
|
||||
@ -1,2 +0,0 @@
|
||||
bundle exec just-the-docs rake search:init
|
||||
bundle exec jekyll serve --livereload
|
||||
@ -1,2 +1,2 @@
|
||||
bundle install
|
||||
bundle exec jekyll serve --force_polling --livereload --incremental
|
||||
bundle exec jekyll serve --force_polling --livereload --incremental
|
||||
Loading…
Reference in new issue