From e3620457190c3e14fc84ccf53b5e1c81c9166af7 Mon Sep 17 00:00:00 2001 From: Aaron Robert Date: Sun, 26 Apr 2020 22:40:59 +0800 Subject: [PATCH] docs: fix typos. (#34) --- CMakeLists.txt | 2 +- README.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index dafe662..47ac895 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -47,7 +47,7 @@ add_library(Greeter ${headers} ${sources}) set_target_properties(Greeter PROPERTIES CXX_STANDARD 17) -# beeing a cross-platform target, we enforce enforce standards conformance on MSVC +# beeing a cross-platform target, we enforce standards conformance on MSVC target_compile_options(Greeter PUBLIC "$<$:/permissive->") # Link dependencies (if required) diff --git a/README.md b/README.md index e3e72f0..b2c9c0e 100644 --- a/README.md +++ b/README.md @@ -107,7 +107,7 @@ Glob is considered bad because any changes to the source file structure [might n > I want create additional targets that depend on my library. Should I modify the main CMakeLists to include them? -Always avoid including derived projects from the from the libraries CMakeLists (even though it is a common sight in the C++ world), as this effectively inverts the dependency tree and makes the build system hard to reason about. +Always avoid including derived projects from the libraries CMakeLists (even though it is a common sight in the C++ world), as this effectively inverts the dependency tree and makes the build system hard to reason about. Instead, create a new directory or project with a CMakeLists that adds the library as a dependency (e.g. like the [standalone](standalone/CMakeLists.txt) directory). Depending type it might make sense move these components into a separate repositories and reference a specific commit or version of the library. This has the advantage that individual libraries and components can be improved and updated independently.