diff options
| -rw-r--r-- | docs/markdown/Comparisons.md | 26 | ||||
| -rw-r--r-- | docs/markdown/Custom-build-targets.md | 2 | ||||
| -rw-r--r-- | docs/markdown/Dependencies.md | 8 | ||||
| -rw-r--r-- | docs/markdown/FAQ.md | 2 | ||||
| -rw-r--r-- | docs/markdown/Installing.md | 4 | ||||
| -rw-r--r-- | docs/markdown/Using-multiple-build-directories.md | 4 | ||||
| -rw-r--r-- | docs/markdown/Wrap-review-guidelines.md | 2 | ||||
| -rw-r--r-- | docs/markdown/howtox.md | 2 |
8 files changed, 25 insertions, 25 deletions
diff --git a/docs/markdown/Comparisons.md b/docs/markdown/Comparisons.md index 3c526ad..dcfefa9 100644 --- a/docs/markdown/Comparisons.md +++ b/docs/markdown/Comparisons.md @@ -2,7 +2,7 @@ title: Comparisons ... -# Comparing Meson with other build systems # +# Comparing Meson with other build systems A common question is *Why should I choose Meson over a different build system X?* There is no one true answer to this as it depends on the @@ -11,37 +11,37 @@ to build medium-to-large projects so the decision is usually made on other points. Here we list some pros and cons of various build systems to help you do the decision yourself. -## GNU Autotools ## +## GNU Autotools -### Pros ### +### Pros Excellent support for legacy Unix platforms, large selection of existing modules. -### Cons ### +### Cons Needlessly slow, complicated, hard to use correctly, unreliable, painful to debug, incomprehensible for most people, poor support for non-Unix platforms (especially Windows). -## CMake ## +## CMake -### Pros ### +### Pros Great support for multiple backends (Visual Studio, XCode, etc). -### Cons ### +### Cons The scripting language is cumbersome to work with. Some simple things are more complicated than necessary. -## SCons ## +## SCons -### Pros ### +### Pros Full power of Python available for defining your build. -### Cons ### +### Cons Slow. Requires you to pass your configuration settings on every invocation. That is, if you do `scons OPT1 OPT2` and then just @@ -61,9 +61,9 @@ Implemented in Java. Poor Windows support. Heavily focused on Google's way of doing things (which may be a good or a bad thing). Contributing code requires [signing a CLA](https://bazel.build/contributing.html). -## Meson ## +## Meson -### Pros ### +### Pros The fastest build system [see measurements](Performance-comparison.md), user friendly, designed to @@ -71,7 +71,7 @@ be as invisible to the developer as possible, native support for modern tools (precompiled headers, coverage, Valgrind etc). Not Turing complete so build definition files are easy to read and understand. -### Cons ### +### Cons Relatively new so it does not have a large user base yet, and may thus contain some unknown bugs. Visual Studio and XCode backends not as diff --git a/docs/markdown/Custom-build-targets.md b/docs/markdown/Custom-build-targets.md index 8bd31db..30a16e3 100644 --- a/docs/markdown/Custom-build-targets.md +++ b/docs/markdown/Custom-build-targets.md @@ -27,7 +27,7 @@ This would generate the binary `output.bin` and install it to `${prefix}/subdir/output.bin`. Variable substitution works just like it does for source generation. -## Details on compiler invocations ## +## Details on compiler invocations Meson only permits you to specify one command to run. This is by design as writing shell pipelines into build definition files leads to diff --git a/docs/markdown/Dependencies.md b/docs/markdown/Dependencies.md index c46334c..c3f007f 100644 --- a/docs/markdown/Dependencies.md +++ b/docs/markdown/Dependencies.md @@ -47,7 +47,7 @@ The dependency detector works with all libraries that provide a `pkg-config` file. Unfortunately several packages don't provide pkg-config files. Meson has autodetection support for some of these. -## Boost ## +## Boost Boost is not a single dependency but rather a group of different libraries. To use Boost headers-only libraries, simply add Boost as a @@ -76,7 +76,7 @@ environment variables. You can set the argument `threading` to `single` to use boost libraries that has been compiled for single-threaded use instead. -## GTest and GMock ## +## GTest and GMock GTest and GMock come as sources that must be compiled as part of your project. With Meson you don't have to care about the details, just @@ -84,7 +84,7 @@ pass `gtest` or `gmock` to `dependency` and it will do everything for you. If you want to use GMock, it is recommended to use GTest as well, as getting it to work standalone is tricky. -## MPI ## +## MPI MPI is supported for C, C++ and Fortran. Because dependencies are language-specific, you must specify the requested language using the @@ -100,7 +100,7 @@ are not in your path, they can be specified by setting the standard environment variables `MPICC`, `MPICXX`, `MPIFC`, `MPIF90`, or `MPIF77`, during configuration. -## Qt5 ## +## Qt5 Meson has native Qt5 support. Its usage is best demonstrated with an example. diff --git a/docs/markdown/FAQ.md b/docs/markdown/FAQ.md index 2023c7e..441cd69 100644 --- a/docs/markdown/FAQ.md +++ b/docs/markdown/FAQ.md @@ -98,7 +98,7 @@ The only reason why one would use Make instead of Ninja is working on a platform Just use Ninja, you'll be happier that way. I guarantee it. -## Why is Meson not just a Python module so I could code my build setup in Python? ## +## Why is Meson not just a Python module so I could code my build setup in Python? A related question to this is *Why is Meson's configuration language not Turing-complete?* diff --git a/docs/markdown/Installing.md b/docs/markdown/Installing.md index 3454d49..2663ff4 100644 --- a/docs/markdown/Installing.md +++ b/docs/markdown/Installing.md @@ -44,7 +44,7 @@ giving an absolute install path. install_data(sources : 'foo.dat', install_dir : '/etc') # -> /etc/foo.dat ``` -## Custom install behavior ## +## Custom install behavior Sometimes you need to do more than just install basic targets. Meson makes this easy by allowing you to specify a custom script to execute at install time. As an example, here is a script that generates an empty file in a custom directory. @@ -65,7 +65,7 @@ meson.add_install_script('myscript.sh') The argument is the name of the script file relative to the current subdirectory. -## DESTDIR support ## +## DESTDIR support Sometimes you need to install to a different directory than the install prefix. This is most common when building rpm or deb packages. This is done with the `DESTDIR` environment variable and it is used just like with other build systems: diff --git a/docs/markdown/Using-multiple-build-directories.md b/docs/markdown/Using-multiple-build-directories.md index c07b39c..2455640 100644 --- a/docs/markdown/Using-multiple-build-directories.md +++ b/docs/markdown/Using-multiple-build-directories.md @@ -8,7 +8,7 @@ Secondly this makes it very easy to clean your projects: just delete the build s The true benefit comes from somewhere else, though. -## Multiple build directories for the same source tree ## +## Multiple build directories for the same source tree Since a build directory is fully self contained and treats the source tree as a read-only piece of data, it follows that you can have arbitrarily many build trees for any source tree at the same time. Since all build trees can have different configuration, this is extremely powerful. Now you might be wondering why one would want to have multiple build setups at the same time. Let's examine this by setting up a hypothetical project. @@ -36,7 +36,7 @@ The cross compilation file sets up Wine so that not only can you compile your ap To compile any of these build types, just cd into the corresponding build directory and run `ninja` or instruct your IDE to do the same. Note that once you have set up your build directory once, you can just run Ninja and Meson will ensure that the resulting build is fully up to date according to the source. Even if you have not touched one of the directories in weeks and have done major changes to your build configuration, Meson will detect this and bring the build directory up to date (or print an error if it can't do that). This allows you to do most of your work in the default directory and use the others every now and then without having to babysit your build directories. -## Specialized uses ## +## Specialized uses Separate build directories allows easy integration for various different kinds of tools. As an example, Clang comes with a static analyzer. It is meant to be run from scratch on a given source tree. The steps to run it with Meson are very simple. diff --git a/docs/markdown/Wrap-review-guidelines.md b/docs/markdown/Wrap-review-guidelines.md index 39acadc..512353c 100644 --- a/docs/markdown/Wrap-review-guidelines.md +++ b/docs/markdown/Wrap-review-guidelines.md @@ -7,7 +7,7 @@ package is rejected. What should be done will be determined on a case-by-case basis. Similarly meeting all these requirements does not guarantee that the package will get accepted. Use common sense. -## Checklist ## +## Checklist Reviewer: copy-paste this to MR discussion box and tick all boxes that apply. diff --git a/docs/markdown/howtox.md b/docs/markdown/howtox.md index 2dd5ddf..e5c03ce 100644 --- a/docs/markdown/howtox.md +++ b/docs/markdown/howtox.md @@ -97,7 +97,7 @@ $ ninja coverage-html (or coverage-xml) The coverage report can be found in the meson-logs subdirectory. -## Add some optimization to debug builds ## +## Add some optimization to debug builds By default the debug build does not use any optimizations. This is the desired approach most of the time. However some projects benefit from having some minor optimizations enabled. GCC even has a specific compiler flag `-Og` for this. To enable its use, just issue the following command. |