Adding fixes and properties

README.md

@@ -1,7 +1,5 @@
 # An Introduction to Modern CMake
 
-
-
 People love to hate build systems.
 Just watch the talks from CppCon17 to see examples of developers making the state of build systems the brunt of jokes.
 This raises the question: Why?
@@ -15,7 +13,7 @@ And CMake 3.11 is significantly faster, as well!
 
 
 {% hint style='working' %}
-This document is a work in progress.
+This document is a work in progress. You can raise an issue or put in a merge request on [GitLab](https://gitlab.com/CLIUtils/modern-cmake).
 {% endhint %}
 
 In short, here are the most likely questions in your mind if you are considering Modern CMake:

chapters/installing.md

@@ -44,10 +44,10 @@ This has the benefit of respecting your current virtual environment, as well.
 
 {% hint style='info' %}
 Personally, on Linux, I put versions of CMake in folders, like `/opt/cmake39` or `~/opt/cmake39`, and then add them to [LMod]. See [`envmodule_setup`][envmodule_setup] for help setting up an LMod system on macOS or Linux. It's takes a bit to learn, but is a great way to manage package and compiler versions.
+[envmodule_setup]: https://github.com/CLIUtils/envmodule_setup
 {% endhint %}
 
 [^1]: If don't have a `.local` in your home directory, it's easy to start. Just make the folder, then add `export PATH="$HOME/.local/bin:$PATH"` to your `.bashrc` or `.bash_profile` or `.profile` file in your home directory. Now you can install any packages you build to `-DCMAKE_INSTALL_PREFIX=~/.local` instead of `/usr/local`!
 
 [cmake-download]: https://cmake.org/download/
 [LMod]: http://lmod.readthedocs.io/en/latest/
-[envmodule_setup]: https://github.com/CLIUtils/envmodule_setup

chapters/options.md

@@ -34,8 +34,35 @@ Since `BOOL` is such a common variable type, you can set it more succinctly with
  
 For the `BOOL` datatype, there are several different wordings for `ON` and `OFF`.
 
+See [cmake-variables] for a listing of known variables in CMake.
+
 ## The Cache
  
 The cache is actually just a text file, `CMakeCache.txt`, that gets created in the build directory when you run CMake. This is how CMake remembers anything you set, so you don't have to re-list your options every time you rerun CMake. 
 
+## Properties
+
+The other way CMake stores information is in properties. This is like a variable, but it is attached to some other item, like a directory or a target. A global property can be a useful uncached global variable. Many target properties are initialized from a matching variable with `CMAKE_` at the front. So setting `CMAKE_CXX_STANDARD`, for example, will mean that all new targets created will have `CXX_STANDARD` set to that when they are created. There are two
+ways to set properties:
+
+```cmake
+set_property(TARGET TargetName
+             PROPERTY CXX_STANDARD 11)
+
+set_target_properties(TargetName PROPERTIES
+                      CXX_STANDARD 11)
+```
+
+The first form is more general, and can set multiple targets/files/tests at once, and has useful options. The second is a shortcut for setting several properties on one target. And you can get targets similarly:
+
+```cmake
+get_property(ResultVariable TARGET TargetName PROPERTY CXX_STANDARD)
+```
+
+See [cmake-properties] for a listing of all known properties. You can also make your own in some cases.[^2]
+
+[cmake-properties]: https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html
+[cmake-variables]: https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html
+
 [^1]: `if` statements are a bit odd in that they can take the variable with or without the surrounding syntax; this is there for historical reasons: `if` predates the `${}` syntax.
+[^2]: Interface targets, for example, may have limits on custom properties that are allowed.