Maybe a newbie question but. Any ideas why building with CLion throw links errors, but manually not? I missing some extra-configuration on the CLions side?

Testcase:

• In CLion, define a profile with an alternative compiler (for me, it's clang-10)
• Clear the conan cache
• Have CLion regenerate the project

Expected result

• This should complete without errors, and allow the project to be built
  • All conan packages should be build

Actual result

• CLion calls something along the lines of
  /home/kees-jan/opt/clion-2019.3.5/bin/cmake/linux/bin/cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=/usr/bin/clang-10 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-10 -G "CodeBlocks - Unix Makefiles" /home/kees-jan/src/cpp_starter_project
• This triggers conan to build the dependencies
• That fails (among others in docopt) with

CMake Error at conanbuildinfo.cmake:553 (message):
  Incorrect 'clang', is not the one detected by CMake: 'GNU'
Call Stack (most recent call first):
  conanbuildinfo.cmake:136 (conan_check_compiler)
  CMakeLists.txt:5 (CONAN_BASIC_SETUP)

Analysis

• Conan expects the CC and CXX variables to be set, in addition to the compiler settings, and they are not.
• I'm not sure whether to blame CLion, CMake, Conan, or this starter project for that shortcoming

Adding docker support would make the developer environment expected by this starter project portable.

Setting up all the various executables expected by the cmake file is a little bit of a hinderance to productivity when setting up.

Hi Jason,

Thanks a bunch for this starter project and all your videos.
I cloned the project today and tried to build and ran into a link issue with the fmt library. It compiles fine if I remove the calls to fmt and spdlog.
I have attached the build output. I hope I'm not making some rookie mistake.

Thanks again for all your hard work.
cpp_starter_link_fmt_fail.txt

EDIT: I'm running pop!os : 19.04 and upgraded cmake to version 17.

A couple of weeks ago, Github added a 'template repository' feature. Here's a blog post about it. When I first heard about it, I thought of this project, since this project is meant to be a reusable project template.

I enabled the template repository feature on my fork, if you'd like to see what it looks like. The template feature adds a big green button labelled 'Use this template', and when you click it, it lets you make a new repository on your account that's pre-populated with all the files in the template repository. To me, it seems less messy than git clone <cpp_starter_prj> && rm -rf .git && git init && git add -A && git remote add origin <new_repo> && oh noes i forgot something or made a mistake.

To enable the feature, all you have to do is click on 'Settings' and then click the box labelled 'Template Repository'. I would make a pull request, but this is a Github setting and not something you can commit.

Our documentation states that VS 2017 can build this project, but it has been my experience that it cannot. I think we should either change the documentation to say that VS 2019 is required, or document some workaround for the problem.

I made an AppVeyor build using Visual Studio 2017 for this project, and it consistently produces this warning, which causes the build to fail:

catch.hpp(2167): warning C4619: #pragma warning: there is no warning number '4800'

There's an issue for this filed in Catch2's github, but it's closed as a won't-fix. There's an issue filed at MSDN, but they closed it by saying "We fixed it in VS 2019".

I ported a code base from qmake to cmake and have started cleaning up compiler warnings. In doing so, I noticed that the cpp files generated by QT's Automoc triggers warnings on -Wundefined-reinterpret-cast and -Wuseless-cast.

There isn't much that can be done to fix the warnings since the code is autogenerated by qt. Since I reference this repo for handy defaults I thought I would post this to see if it would help others as a good default.

To fix this in my project I added the following lines to my CMake file:

# Ignore warnings related to autogenerated code from MOC
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/[project_name]_autogen/mocs_compilation.cpp PROPERTIES COMPILE_FLAGS "-Wno-undefined-reinterpret-cast")
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/[project_name]_autogen/mocs_compilation.cpp PROPERTIES COMPILE_FLAGS "-Wno-useless-cast")

Built with both ENABLE_CLANG_TIDY and DENABLE_PCH=ON enabled, clang-tidy threw errors about PCH format unrecognized

error: file '.../build/test/CMakeFiles/tests.dir/cmake_pch.hxx.gch' is not a valid precompiled PCH file [clang-diagnostic-error]
error: input is not a PCH file: '.../build/test/CMakeFiles/tests.dir/cmake_pch.hxx.gch' [clang-diagnostic-error]
2 errors generated.
Error while processing .../test/tests.cpp.
Found compiler error(s).

$ clang-tidy --version
LLVM (http://llvm.org/):
  LLVM version 9.0.0
  
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: ivybridge

P.S. I tried to limit clang-tidy to specified targets, but PCH file implicitly included in all cpp files, so this way a dead end

The compilation invokes g++ with -Wduplicated-branches, which was only introduced in GCC 8.x, it seems. My distribution uses GCC 6.x, so my build fails.

Either GCC 6.x (and 7.x I think) should be unsupported, or the warning needs to be dropped for GCC 8.x

Sorry if this is a stupid question, but I can't for the life of me figure out how to fix this CRT linker issue. My test_nana executable and my Nana lib cannot agree on run-time libraries.

I've used a template to set up a new project, removed all frameworks except Nana, and set up using MSVC build. The problem is that there seems to be conflicting link types between the Nana example executable and the Nana lib. I cannot remember actively choosing either link type. Can this be specified in the project somewhere, or are these settings magically lifted from elsewhere?

It does appear to be mentioning a triplet from vcpkg for whatever reason, even though the project does not use vcpkg as far as I can tell?

I've tried changing the CMAKE_CACHE_ARGS "-DNANA_CMAKE_SHARED_LIB:BOOL=TRUE" to FALSE in the nana\CMakeLists.txt file, but it doesn't seem to make a difference.

  Building Custom Rule D:/Code/github/nana_test/test/CMakeLists.txt
  Using triplet "x64-windows" from "D:\Code\vcpkg\installed\x64-windows\"
  constexpr_tests.cpp
  relaxed_constexpr_tests.vcxproj -> D:\Code\github\nana_test\build\test\Release\relaxed_constexpr_tests.exe
  Building Custom Rule D:/Code/github/nana_test/src/nana/CMakeLists.txt
  Using triplet "x64-windows" from "D:\Code\vcpkg\installed\x64-windows\"
  main.cpp
nana.lib(basis.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in main.obj [D:\Code\github\nana_test\build\src\nana\test_nana.vcxproj]
nana.lib(events_operation.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in main.obj [D:\Code\github\nana_test\build\src\nana\test_nana.vcxproj]
nana.lib(programming_interface.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in main.obj [D:\Code\github\nana_test\build\src\nana\test_nana.vcxproj]
nana.lib(widget.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in main.obj [D:\Code\github\nana_test\build\src\nana\test_nana.vcxproj]

Sorry for maybe a silly and obvious question, but since I'm qmake user switching to cmake.. why is that it's not CompilerWarnings.cmake that defines that INTERFACE fake-library called project_warnings to be used in all targets you might need? CompilerWarnings.cmake would seem kinda more "complete" if it did by itself.

Or is there some sort of CMake limitation, or better flexibility to do that in two-step: helper .cmake has a function, but target created on the root CMakeLists.txt?

Thanks!

Whenever I want to use this project, I have to copy a bunch of boilerplate Cmake code to different places, which is rather inconvenient and error-prone. It would be nice if the code can become a Cmake library to solve this issue of copying.

By library I mean something similar to ixm:
https://ixm.one/

This is all I need to install ixm:

include(FetchContent)
FetchContent_Declare(ixm URL https://get.ixm.one)
FetchContent_MakeAvailable(ixm)

### When the project is compiled with msys2, the following outputs are seen. How could it be fixed.

Eclipse version is set to 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this is wrong.
ccache found and enabled
Conan: checking conan executable
Conan: Found program /d/Programs/Python39/Scripts/conan.exe
Conan: Version found Conan version 1.30.2

Conan: Adding bincrafters remote repository (https://api.bintray.com/conan/bincrafters/public-conan)
Conan: Automatic detection of conan settings from cmake
CMake Error at build/conan.cmake:112 (message):
cmake system MSYS is not supported by conan. Use one of
Windows;Linux;Macos;Android;iOS;FreeBSD;WindowsStore
Call Stack (most recent call first):
build/conan.cmake:496 (conan_cmake_settings)
cmake/Conan.cmake:16 (conan_cmake_run)
CMakeLists.txt:78 (run_conan)

Configuring incomplete, errors occurred!
See also "/d/github/cpp_starter_project/build/CMakeFiles/CMakeOutput.log".

ubuntu 16.04

~/cpp_starter_project$ g++ main.cpp
main.cpp: In function ‘int main()’:
main.cpp:6:4: warning: lambda capture initializers only available with -std=c++14 or -std=gnu++14
out = std::ref(std::cout << "Hello ") { out.get() << "World\n"; }
^
main.cpp:6:10: error: ‘ref’ is not a member of ‘std’
out = std::ref(std::cout << "Hello ") { out.get() << "World\n"; }
^
main.cpp: In lambda function:
main.cpp:6:47: error: ‘out’ was not declared in this scope
out = std::ref(std::cout << "Hello ") { out.get() << "World\n"; }
^
main.cpp: In function ‘int main()’:
main.cpp:6:71: warning: lambda expressions only available with -std=c++11 or -std=gnu++11
out = std::ref(std::cout << "Hello ") { out.get() << "World\n"; }

is this a version error? how could i correct.

The CMake module StaticAnalyzers.cmake IMHO should be as source independent as possible, currently, it has a reference to imgui/lib folder.

Hey, so my setup is nvim+coc+clangd and it was showing fake compiler warnings at the top of main.cpp with the source of the warning [clang: -Wunknown-warning-option]

Is this is a problem for others because I found a fix for it? Just need to add -Wno-unknown-warning-option to the CLANG_WARNINGS.

I can make a pull request but wanted to ask before I do it.

Hi again,
I finished writing GitHub workflows on my repo. This is another simple thing for someone else to copy over.
I'd do it, but it requires minor modifications (tweaking test building targets and removing CI_BUILD env var) and I've already spent 15 or so hours in a row working on it so I feel pretty burnt out.

The tweaks that have to be made might be good to also adopt in this project:

• I created a custom target for each type of tests that depends on all corresponding test type targets so that making them doesn't require making code from src dir. Tests will likely depend on it, but it's nice to have a group target you can build.
• CI_BUILD is there to allow in-source builds for the CI as I've disabled them by default. My .gitignore ignores CMakeCache.txt which means that running "cmake ." from the root directory won't cause any damage.

Feel free to copy them over. They're MIT licensed.

Another thing I was considering is separating the "C/C++ CI" action into individual actions for each OS so that it's clearer which build is failing. And maybe modify Linux matrix to continue building with GCC if Clang fails and the other way around.

Caching might be also good to implement as it would reduce time pipelines are running and it's limited (likely a non-issue).

Oh, and, windows build failed due to missing spdlog.h even though conan said it was downloaded fine, probably a hiccup as it worked fine past 2/3 times.

When I write a library using the template and an application also using the template cmake returns an error.

CMake Error at ../CMakeLists.txt:9 (add_library):
  add_library cannot create target "project_options" because another target
  with the same name already exists.  The existing target is an interface
  library created in source directory
  "/home/ebony/git/Ebony-Ayers/fwds/test".  See documentation for policy
  CMP0002 for more details.


CMake Error at ../CMakeLists.txt:21 (add_library):
  add_library cannot create target "project_warnings" because another target
  with the same name already exists.  The existing target is an interface
  library created in source directory
  "/home/ebony/git/Ebony-Ayers/fwds/test".  See documentation for policy
  CMP0002 for more details.

The main CMakeLists.txt is setup to require libraries for the settings and warnings. I cannot find a way of removing the libraries with out losing the warnings and settings.

Is there a way remedy this?

CMake run fails with an error at a conan call.

-- The CXX compiler identification is GNU 10.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++-10 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- ccache found and enabled
-- Downloading conan.cmake from https://github.com/conan-io/cmake-conan
-- Conan: checking conan executable
-- Conan: Found program /home/sascha/.local/bin/conan
-- Conan: Version found Conan version 1.23.0

-- Conan: Adding bincrafters remote repository (https://api.bintray.com/conan/bincrafters/public-conan)
-- Conan: Automatic detection of conan settings from cmake
-- Conan: Settings= -s;build_type=Debug;-s;compiler=gcc;-s;compiler.version=10;-s;compiler.libcxx=libstdc++11
-- Conan: checking conan executable
-- Conan: Found program /home/sascha/.local/bin/conan
-- Conan: Version found Conan version 1.23.0

-- Conan executing: /home/sascha/.local/bin/conan install . -s build_type=Debug -s compiler=gcc -s compiler.version=10 -s compiler.libcxx=libstdc++11 -g=cmake --build=missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=10
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

conanfile.txt: Installing package
Requirements
    catch2/2.13.3 from 'conan-center' - Cache
    docopt.cpp/0.6.2 from 'conan-center' - Cache
    fmt/6.2.0 from 'conan-center' - Cache
    spdlog/1.5.0 from 'conan-center' - Cache
Packages
    catch2/2.13.3:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
    docopt.cpp/0.6.2:a25d6c83542b56b72fdaa05a85db5d46f5f0f71c - Cache
    fmt/6.2.0:a25d6c83542b56b72fdaa05a85db5d46f5f0f71c - Cache
    spdlog/1.5.0:270d3115ab09f4c4851a4e1dfbd2e97254780788 - Cache

Installing (downloading, building) binaries...
catch2/2.13.3: Already installed!
docopt.cpp/0.6.2: Already installed!
WARN: spdlog/1.5.0: requirement fmt/6.2.1 overridden by your conanfile to fmt/6.2.0 
ERROR: docopt.cpp/0.6.2: Error in package_info() method, line 74
	self.cpp_info.components["docopt"].names["cmake_find_package"] = cmake_target
	TypeError: '_CppInfo' object is not subscriptable
CMake Error at cmake-build-debug-gcc-10/conan.cmake:402 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  cmake-build-debug-gcc-10/conan.cmake:497 (conan_cmake_install)
  cmake/Conan.cmake:16 (conan_cmake_run)
  CMakeLists.txt:76 (run_conan)


-- Configuring incomplete, errors occurred!
See also "/home/sascha/Repositories/External/cpp_starter_project/cmake-build-debug-gcc-10/CMakeFiles/CMakeOutput.log".

[Finished]

I am not understanding how:

# Link to project_options library to set compiler and sanitizer options
add_library(project_options INTERFACE)
target_compile_features(project_options INTERFACE cxx_std_17)

# Link to project_warnings library to set compiler warnings
add_library(project_warnings INTERFACE)
include(cmake/CompilerWarnings.cmake)
set_project_warnings(project_warnings)

Sets options on the project. The two "libraries" don't appear to be linked in anywhere, at least, that's how it appears in my project.

Would be great to have GSL as an option.

I am on pop_os 20.0.4 and using the latest CLion.

When I load the CMakeLists.txt, I get:

/app/extra/clion/bin/cmake/linux/bin/cmake -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - Unix Makefiles" /home/jeff/projects/personal/cpp_starter_project
-- ccache found and enabled
-- Conan: checking conan executable
CMake Error at cmake-build-debug/conan.cmake:531 (message):
  Conan executable not found!

Conan is installed with pip3 globally and a which conan on the command line gives me this:

/usr/local/bin/conan

I don't have python (python2 installed). Everything everything is python3 and pip3. Might that be the problem?

$ cmake-format -i CMakeLists.txt 
WARNING config_util.py:309: The following configuration options were ignored:
  max_subargs_per_line

$ cmake-format --version
0.6.9

Probably as a result, the cmake files are not formatted conform the .cmake-format.yaml file.

On macOS: When I do mkdir build-cpp_starter_project && cd build-cpp_starter_project && cmake ../cpp_starter_project I get

...
ERROR: Requested 'catch2/2.11.0' but found case incompatible 'Catch2'
Case insensitive filesystem can't manage this
CMake Error at /Users/benfrantzdale/code/other/build-cpp_starter_project/conan.cmake:402 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  /Users/benfrantzdale/code/other/build-cpp_starter_project/conan.cmake:497 (conan_cmake_install)
  cmake/Conan.cmake:16 (conan_cmake_run)
  CMakeLists.txt:65 (run_conan)

If I delete my ~/.conan directory, it builds, but then when I go to make I get

 $ make
Scanning dependencies of target catch_main
[ 10%] Building CXX object test/CMakeFiles/catch_main.dir/catch_main.cpp.o
In file included from /Users/benfrantzdale/code/other/cpp_starter_project/test/catch_main.cpp:3:
/Users/benfrantzdale/.conan/data/catch2/2.11.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/catch2/catch.hpp:482:63: error: expected ';' at end of declaration list
        SourceLineInfo( char const* _file, std::size_t _line ) noexcept
                                                              ^
...
/Users/benfrantzdale/.conan/data/catch2/2.11.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/catch2/catch.hpp:640:63: error: expected ';' at end of declaration list
        auto substr( size_type start, size_type length ) const noexcept -> StringRef;
                                                              ^
/Users/benfrantzdale/.conan/data/catch2/2.11.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/catch2/catch.hpp:643:9: error: 'auto' not allowed in function return type
        auto data() const noexcept -> char const*;
        ^~~~
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[2]: *** [test/CMakeFiles/catch_main.dir/catch_main.cpp.o] Error 1
make[1]: *** [test/CMakeFiles/catch_main.dir/all] Error 2
make: *** [all] Error 2
$

which makes it look like it's trying to build catch2 but isn't in C++17 mode. FWIW, https://github.com/bugwelle/cpp-starter-project works (and is why my Conan had Catch2).

With MacOS Mojave(10.14.6) and Apple clang version 11.0.0 (clang-1100.0.33.17), compiler string is AppleClang so same string needs to be used here. Though not sure if it's different per Mac OS version.

¡Hello!
I've tryed this template to a personal project and when I have an error on my code, vscode output shows some unreadable characters.

[build]  #include �[01;31m�[K<SDL2/SDL.h>�[m�[K
[build]           �[01;31m�[K^~~~~~~~~~~~�[m�[K

I've checked all fonts, and I dones't look to solve anything.
Those characters just appears using this template, and I can't fix it.

If someone can help me please.

Currently a specific version of CMake is specified in the CMakeLists.txt:

https://github.com/lefticus/cpp_starter_project/blob/d7a2b6b891d75edc68c9d88dca7e24cd73e378b8/CMakeLists.txt#L1

CMake makes it however also possible (3.12 feature, but backwards compatible) to indicate a version range by using the format:

cmake_minimum_required(VERSION <min>[...<max>])

for example:

cmake_minimum_required(VERSION 3.13...3.17)

This makes it easier to use a wider range of CMake versions. Updating CMake on CI systems is sometimes difficult and proving a range could help to see that the current CMake version is already compatible.

A recent commit (b0edb4b) added code that causes the build to fail if CMake detects an in-source build.

The ccmake directions in the README unambiguously tell you to run the configuration in the source directory, not the build directory. I tried following these directions, and they trigger a fatal error due to the in-source build. I think the documentation needs to be updated so that it doesn't guide new users directly into this fatal error.

The starter project assumes the location of the executables like Clang Tidy. I'm using CLion and VSCode. Please add a sample comment showing how to allow CMake to find the missing executables.

The cmake script for Conan is outdated and is not aligned to the suggested use of the https://github.com/conan-io/cmake-conan wrapper. See the linked repository readme for last suggested way of using the wrapper.

The current CI builds do not check to see if the GUI examples build successfully. It would be really helpful for the CI to tell us whether or not a change would break the examples.

While writing #121 I noticed that both the Nana and Qt examples produce warnings, which lead to build failures, unless you define WARNINGS_AS_ERRORS=FALSE. As a result, I had to add some code to #121 that really doesn't belong there, just to prove that my branch works. CI tests would have revealed these problems a long time ago:

• The Qt example fails because of a stray semicolon at src/qt/HelloQt.cpp line 38.
• The Nana example fails because the Nana header files have some shadowed variable names, which triggers -Wshadow.

Building the examples should be as frictionless as possible, and CI builds would really help with that. What better way to destroy user confidence is there than to provide examples that don't work?

If anyone is interested in adding these CI tests, you may find it useful to read the build_examples.sh and Dockerfile files in #121, or the Dockerfile in #99. Building the examples is not as straightforward as I would like it to be.

Edit: Since #134 and #121 were merged, the compilation failures described here should be resolved.

I enabled sdl and tried to build it and installing through conan throws a bunch of errors asking for packages that need to be installed like libxcb-xkb-dev and a bunch more. Other libraries with spdlog installed gracefully. Maybe it's something wrong with my machine? it's a clean ubuntu 20 build

Actually, After giving up trying to get sdl to work through conan I tried getting im-gui sfml to work and it also has similar dependency problems.

I'm attempting to build a new project using this template and Clang.

I followed the instructions to install the apps via choco, expect I already had Visual Studio Enterprise installed, so I skipped that bit. I added everything to the Path. I also added CC and CCX environment variables. I selected "Visual Studio 16 2019" as the generator, ClangCl as the Optional toolset, and checked "use default native compilers" Upon configuring in cmake-gui, I get the following output.

Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
The CXX compiler identification is Clang 10.0.0 with MSVC-like command-line
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
Detecting CXX compile features
Detecting CXX compile features - done
ccache found and enabled
Conan: checking conan executable
Conan: Found program C:/Program Files/Conan/conan/conan.exe
Conan: Version found Conan version 1.32.0

Conan: Adding bincrafters remote repository (https://api.bintray.com/conan/bincrafters/public-conan)
Conan: Using cmake-multi generator
Conan: Automatic detection of conan settings from cmake
clang-cl
: warning: unknown argument ignored in clang-cl: '-x' [-Wunknown-argument]

clang-cl
: warning: unknown argument ignored in clang-cl: '-dM' [-Wunknown-argument]

clang-cl
: error: no such file or directory: 'c++'

Conan: Settings= -s;build_type=Release;-s;compiler=clang;-s;compiler.version=10;-s;compiler.libcxx=libc++
Conan: checking conan executable
Conan: Found program C:/Program Files/Conan/conan/conan.exe
Conan: Version found Conan version 1.32.0

Conan executing: C:/Program Files/Conan/conan/conan.exe install . -s build_type=Release -s compiler=clang -s compiler.version=10 -s compiler.libcxx=libc++ -g=cmake_multi --build=missing
Configuration:

[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=clang
compiler.libcxx=libc++
compiler.version=10
os=Windows
os_build=Windows
[options]
[build_requires]
[env]


conanfile.txt: 
Installing package
Requirements
    catch2/2.11.0 from 'conan-center' - Cache
    docopt.cpp/0.6.2 from 'conan-center' - Cache
    fmt/6.2.0 from 'conan-center' - Cache
    spdlog/1.5.0 from 'conan-center' - Cache
Packages
    catch2/2.11.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
    docopt.cpp/0.6.2:96ea241aa3076f4628e6ccc36aec6371370a7e39 - Build
    fmt/6.2.0:96ea241aa3076f4628e6ccc36aec6371370a7e39 - Build
    spdlog/1.5.0:3a5fa269c7789182033bca003043705da37ce3d1 - Build


Installing (downloading, building) binaries...

catch2/2.11.0: 
Already installed!

docopt.cpp/0.6.2: 
Copying sources to build folder

docopt.cpp/0.6.2: 
Building your package in C:\Users\gary\.conan\data\docopt.cpp\0.6.2\_\_\build\96ea241aa3076f4628e6ccc36aec6371370a7e39

docopt.cpp/0.6.2: 
Generator cmake created conanbuildinfo.cmake

docopt.cpp/0.6.2: 
Calling build()

CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.


CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.

CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage

-- Configuring incomplete, errors occurred!

docopt.cpp/0.6.2: 


WARN: spdlog/1.5.0: requirement fmt/6.2.1 overridden by your conanfile to fmt/6.2.0 
docopt.cpp/0.6.2: WARN: Package binary is corrupted, removing: 96ea241aa3076f4628e6ccc36aec6371370a7e39
docopt.cpp/0.6.2: WARN: Build folder is dirty, removing it: C:\Users\gary\.conan\data\docopt.cpp\0.6.2\_\_\build\96ea241aa3076f4628e6ccc36aec6371370a7e39
docopt.cpp/0.6.2: ERROR: Package '96ea241aa3076f4628e6ccc36aec6371370a7e39' build failed
docopt.cpp/0.6.2: WARN: Build folder C:\Users\gary\.conan\data\docopt.cpp\0.6.2\_\_\build\96ea241aa3076f4628e6ccc36aec6371370a7e39
ERROR: docopt.cpp/0.6.2: Error in build() method, line 58
	cmake = self._configure_cmake()
while calling '_configure_cmake', line 52
	self._cmake.configure(build_folder=self._build_subfolder)
	ConanException: Error 1 while executing cd C:\Users\gary\.conan\data\docopt.cpp\0.6.2\_\_\build\96ea241aa3076f4628e6ccc36aec6371370a7e39\build_subfolder && cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE="Release" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="c
lang" -DCONAN_COMPILER_VERSION="10" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DCONAN_LIBCXX="libc++" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="C:\Users\gary\.conan\data\docopt.cpp\0.6.2\_\_\package\96ea241aa3076f4628e6ccc36aec6371370a7e39" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DUSE_BOOST_REGEX="False" -Wno-dev C:\Users\gary\.conan\data\docopt.cpp\0.6.2\_\_\build\96ea241aa3076f4628e6ccc36aec6371370a7e39

CMake Error at build/conan.cmake:402 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  build/conan.cmake:492 (conan_cmake_install)
  cmake/Conan.cmake:16 (conan_cmake_run)
  CMakeLists.txt:76 (run_conan)


Configuring incomplete, errors occurred!
See also "C:/Dev/Code/TheCodeFiend/vulkan-cmake-clang-vs/build/CMakeFiles/CMakeOutput.log".

Dear community, I would like to achieve the following:

• if the code has any warnings generated by either -Wpedantic or /permissive-, the build should fail.

With clang++.exe I can use -pedantic-errors. And I can easily add that to CompilerWarnings.cmake.

Unfortunately, it's not been easy to achieve the same behaviour with clang-cl.exe and /permissive-: the warnings are generated, but the build does not fail with an error. And clang-cl.exe does not support -pedantic-errors.

This behavious is in contradiction with what cl.exe does.
If one adds /std:c++17 /permissive- to cl.exe's options in the command line, the build errors out.

The following code is not C++17 standard compliant, because f's parameter s is missing const:

#include <iostream>
#include <filesystem>

void f(char* s)
{
  std::cout << s;
}

int main(int argc, const char **argv)
{
  std::filesystem::path p;
  f("this should fail");
  return 0;
}

Clang++: https://godbolt.org/z/zs9KWM (failing with -pedantic-errors)
MSVC: https://godbolt.org/z/bq7hxj (failing with /permissive-)

I can't find clang-cl in Compiler Explorer. Maybe there's a flag I can pass to clang?

If one copy/pastes that code in a file and tries to compile it with clang-cl.exe and /permissive- /std:c++17, the build won't error out. It'll only report a warning.

A warning might be enough in very clean codebases. Or, better, codebases that have always had -Werror (or equivalent) enabled.

But it is not enough in other situations, for example in the presence of legacy code. In such a case, the "pedantic" warnings are just lost in the noise.

Am I doing something wrong with these tools, or are you experiencing the same behaviour?
How would you achieve the desired result?

Some projects on Github are starting to use SPDX-License_Identifiers to make it easy for the end-user to identify the license applied to that project / single file. As the cpp_start_project is a great project to copy and paste from, it could he helpful to use these identifiers.
They typical look like:

// Copyright (c) <copyright owner>
// SPDX-License-Identifier: <license identifier>

and can be used in .cpp files, CMakeLists.txt files,.clang-format, etc.

A good example can be found in the https://github.com/microsoft/STL repository.

When unit tests are executed with ctest, each TEST_CASE is invoked separately but the logs are all written to the same xml file. Say there are two TEST_CASEs with the same target tests, then the xml logs of both is written to tests.xml (as configured in test/CMakeLists.txt) and the latter eventually overwrites the logs of the former. So the problem is the hard coded filename --out=test.xml but I am not sure how to fix this properly. (You can use ctest -V to see the invoked commands.)

This is a question, everything is working functionally.

I've compiled the cpp starter and a few episodes of the game, I was interested in how one would package it between distributions and how header only/shared libraries/included libraries work. Everything compiles and is functionally fine, but the ldd output seems very different. Does anyone know where the differences come from, is that distribution specific or maybe something in conan ?

(left ubuntu/right arch)

Based on the recent talk in the North Denver Metro C++ Meetup, do you consider adding ut as an alternative to Catch to this template?

CPack with Modern CMake is a bit tricky. It'd be great to have a template to start from.

what is the recommended way to use libc++ if compiling the project with Clang?
this way feel a bit strange...

if(CMAKE_CXX_COMPILER_ID MATCHES ".*Clang")
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++ -v -pthread -fstandalone-debug")
    set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -stdlib=libc++ -lc++abi")
endif()

If you really want to go the extra mile in providing a good example of how modern CMake should be used, it's arguably a good idea to avoid mentioning the details of tools and tool chains (e.g. specific analysers, package managers, compiler flags etc.) from within the CMakeLists.txt files. Those files should be reserved for describing how the source fits together to make binary artefacts.

The root CMakeLists.txt in particular is doing double duty as a script for enabling many, varied workflows. They could mostly/all be removed from CMake, or isolated into .cmake files which aren't invoked from CMakeLists.txt but are instead invoked using cmake in script mode. The ideal is achieving a clean separation between the build system and the other tools on display in this project.

Examples:

• All of the compiler options could be passing in via the cmake configuration command (e.g. using the language flags variables) or collected into toolchain files (example, more explanation). This makes it easier to add or extend tool chain support.
• The build system could be made package manager-agnostic by removing all reference to Conan. A clean separation is generally encourage by the Conan team, and it's straightforward to achieve using generators such as cmake_find_package.
• Tools like Clang-Tidy can be enabled from outside the CMakeLists.txt files for cleaner separation.

In general, if a variable starts with CMAKE_, then it's ideally passed into the build system, rather than set from inside of it.

I used this project for basis of mine. Throughout tonight I was setting up CI and noticed if-else was forcing gcc arguments for Xcode (macOS) compiler which is based on clang.

Changing line here to:

elseif(CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")

fixes the problem.

Futher, I don't think it's a good idea to put GCC in else as it has most arguments which means that build will fail with most unsupported compilers. GCC should also be strictly chosen and the else block should either error out and ask for custom arguments to be specified or just print out a warning that no warning arguments are provided.

There are some utilities to parse command args but I have no idea how to use them. Any ideas?

I see their purpose. To show how you can use this starter project + library X. But if I would pull the starter project, and I'm not using any of these, I'd have to start by deleting these folders.

It's probably more of a philosophy question.

Do you want people to git clone ... and not have to do anything extra or something else?

Using Catch2's REQUIRE triggers clang-tidy to warn about the usage of var_arg. Disabling cppcoreguidelines-pro-type-vararg and hicpp-vararg globally (in .clang-tidy) or using NOLINT at each invocation of REQUIRE resolves this issue. The former is maybe the easiest solution, the latter the more accurate approach. On the other hand adding NOLINT(cppcoreguidelines-pro-type-vararg, hicpp-vararg) to each an every REQUIRE call is tedious ...

EDIT: this problem occurs since catch2/2.11.3 and will be fixed in future releases: Catch2/issues/1921

For ccpcheck inline suppressions to work, cppcheck has to be launched with the "--inline-sppr" command line argument.

Would be nice to have Google benchmark as one of the optional dependencies

Are there arguments against using /permissive- for MSVC projects?

I think it would be useful to add support for the Google Test framework, in addition to the project's current support for the Catch2 framework.

There are a few issues I usually stumble through when starting a new library project...

• adding import/export attributes that work across platforms
• exporting targets
  • separating public headers vs private headers (ensuring includes are prefixed)
  • generating a package config file

It might be good to have the sample test suite link against the sample library to make sure everything is hooked up properly.