friendlyanon/cmake-init

The missing CMake project initializer

cmake-init - The missing CMake project initializer

cmake-init is an opinionated CMake project initializer that generates CMake projects which are FetchContent ready, separate consumer and developer targets, provide install rules with proper relocatable CMake packages and use modern CMake (3.14+).

Please see the wiki for example outputs of cmake-init and other pragmatic examples of functionality implemented for CMake, like package managers, fuzz testing, superbuilds, etc.

VSCode integration with minimal configuration using presets:

CLion integration with minimal configuration using presets:

If you wish to contact me for anything CMake related, then you may find me in the #cmake channel of the C++ Slack. If what you wish to know is cmake-init specific, then you may also ask questions in this repository's Discussions.

Goals

• Be simple to use
  The script allows you to just mash enter to get you a correctly set up project for an executable. You want a header-only library? Choose h when prompted. Static/shared library? Just choose s when prompted. Simple and correct!
• Create FetchContent ready projects
  This is important, because in the near feature this might allow CMake to consume other projects in a trivial fashion similar to other languages, e.g. in JavaScript's case (npm).
• Cleanly separate developer and consumer targets
  This ties into the previous point as well, but developers and consumers of a project have different needs, and separating targets achieves that goal. A developer should be able to run tests, add warning flags, run benchmarks, etc., while a consumer, such as a package maintainer, generally only wants to build the library or the executable itself, without having to patch around in the CMake scripts. Show some love to your package maintainers!
• Use modern CMake (3.14+)
  There are too many outdated and plain wrong examples on the internet, it's time to change that.
• Make usage of tools easy
  Code coverage (gcov), code linting and formatting (clang-format), static analysis (clang-tidy) and dynamic analysis (sanitizers, valgrind) are all very helpful ways to guide the developer in creating better software, so they should be easy to use.

Relevant conference talks

• Kenneth Hoste - How To Make Package Managers Cry
• Robert Schumacher - Don't package your libraries, write packagable libraries! (Part 1)
• Robert Schumacher - Don't package your libraries, write packagable libraries! (Part 2)
• Craig Scott - Deep CMake for Library Authors

Non-goals

• Cover every possible project structure
  Doing this is pointless as an init script, because there are far too many ways people have been building software, and if you have special needs, you ought to already know CMake and you can set the project up yourself.
• Generate files and show tips for websites other than GitHub
  While I understand the people who are against GitHub (and by proxy Microsoft), it's by far the most used website of its kind, the files and messages specific to it are small in number, and they are easily adapted for any other service.

Install

Make sure you have these programs installed:

• Python 3.8 or newer
• CMake 3.20 or newer (3.21 or newer for C17 or newer projects)
• git
• clang-tidy 14 (optional)
• cppcheck (optional)
• Doxygen < 1.9 (optional)
• LCOV (optional)
• clang-format 14 (optional)
• codespell (optional)
• Package managers: Conan or vcpkg (optional)

---

NOTE

Some of these tools can be used on Windows as well if you want to use Visual Studio, but you have to install these addins:

• https://clangpowertools.com/
• https://github.com/VioletGiraffe/cppcheck-vs-addin

---

This package is available for download from PyPI. You can install this package using pip:

pip install cmake-init

clang-tidy

clang-tidy is a static analysis tool that helps you spot logical errors in your code before it is compiled. This script gives you the option to inherit the clang-tidy preset in your dev preset, enabling the CMake integration for this tool.

CI will always run clang-tidy for you, so it is entirely optional to install and use it locally, but it is recommended.

For Windows users, if you wish to use clang-tidy, then you must install Ninja and set the generator field in your dev preset to Ninja. The reason for this is that only Makefiles and Ninja are supported with CMake for use with clang-tidy. For other generators, this feature is a no-op.

cppcheck

cppcheck is a static analysis tool similar to clang-tidy, however the overlap in what they detect is minimal, so it's beneficial to use both of them. This script gives you the option to inherit the cppcheck preset in your dev preset, enabling the CMake integration for this tool.

CI will always run cppcheck for you, so it is entirely optional to install and use it locally, but it is recommended.

For Windows users, if you wish to use cppcheck, then you must install Ninja and set the generator field in your dev preset to Ninja. The reason for this is that only Makefiles and Ninja are supported with CMake for use with cppcheck. For other generators, this feature is a no-op.

Doxygen

Doxygen is a tool to generate documentation from annotated source code. In conjunction with it, m.css is used for presenting the generated documentation.

The generated projects will have a docs target in developer mode, which can be used to build the documentation into the <binary-dir>/docs/html directory.

After Doxygen is installed, please make sure the doxygen executable exists in the PATH, otherwise you might get confusing error messages.

This documentation can be deployed to GitHub Pages using the docs job in the generated CI workflow. Follow the comments left in the job to enable this.

NOTE: m.css does not work with Doxygen >= 1.9. You can install 1.8.20 to use the docs target. See issues #41 and #48.

LCOV

LCOV is a tool to process coverage info generated by executables that were instrumented with GCC's gcov. This coverage info can be used to see what parts of the program were executed.

The generated projects will have a coverage target in developer mode if the ENABLE_COVERAGE variable is enabled. The reason why a separate target is used instead of CTest's built-in coverage step is because it lacks necessary customization. This target should be run after the tests and by default it will generate a report at <binary-dir>/coverage.info and an HTML report at the <binary-dir>/coverage_html directory.

For Windows users, you may use a similar tool called OpenCppCoverage, for which there is an example script in the generated cmake directory. This script is left as an example, because the Linux VM launches and runs faster in GitHub Actions and so it is used for coverage submission.

clang-format

clang-format is part of the LLVM tool suite similar to clang-tidy. It's a code linter and code formatter, which can be used to enforce style guides.

Two targets are made available to check and fix code in developer mode using the format-check and format-fix targets respectively.

NOTE: the project generates files that are formatted according to clang-format 14. Newer or older versions may format the project differently.

codespell

codespell is a tool to find and fix spelling errors mainly in source code.

Two targets are made available to check and fix spelling errors in developer mode using the spell-check and spell-fix targets respectively.

Package managers

The -p flag can be used to select a package manager for the project. Arguments for the flag can be:

• none: no package manager integration (default)
• conan: Conan integration
• vcpkg: vcpkg integration

When using a package manager, the following packages are used in the generated project:

• fmt for C++, json-c and hedley (exe only) for C projects
• Catch2 as a dev dependency for C++ and C projects

Make sure to read the generated HACKING document to see what needs to be done to fetch dependencies.

Usage

• cmake-init [--c] <path>
  This command will create a CMake project at the provided location and according to the answers given to the prompts. You may pass the -s, -e or -h flags after to quickly create a shared library, executable or a header only library respectively. The --c switch will set the generated project's type to C instead of C++.
• cmake-init --help
  Shows the help screen for more flags and switches.

Licensing

cmake-init is Free Software: You can use, study, share and improve it at your will. Specifically you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

The contents of the directory cmake-init/templates are licensed using the Unlicense license. See the license in that directory for further details.

cmake-init's Issues

Default dependencies for C project when using a package manager

Related to #42

I looked at the available dependencies in Conan Center Index for C and there doesn't seem to be one that strikes me as one that would be nice to use as a default to have as an example. For C++ project, the obvious defaults are fmt (dependency) and Catch2 (dev dependency).

One that I think could be okay is json-c, because it has a proper CMake package that can be consistently consumed via either package managers. This makes setting the install config up for library type projects trivial.
I haven't look at a dev dependency for C projects yet.

Better presets for use with VSCode

The "CMake Tools" extension does not support version 1 of presets. Since it's a popular editor, this should be considered.

Adding it as Github template

Hello great project.
Do you have any plan to turn it into a github template project ?
So that it can be easy to bootstrap a new toy project from.

Packaging

I think a really nice thing a lot of people struggle with would be to help a little bit with packaging. What you think?

Target naming

6089ad5 simplified the main target's name in executable projects and I'm thinking whether the same could be applied to other project types as well. It's customary to double up the name that would normally be when there is only a single target exported from a project.

cmakeMinimumRequired version

cmake-init generates the following CMakePresets.json

{
  "version": 1,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 14,
    "patch": 0
  },

Maybe it's because I don't know cmake, but I really don't understand why it requires version 3.14 of cmake.
Weren't Presets officially added in 3.19?

cmake(1) and cmake-gui(1) now recognize CMakePresets.json and CMakeUserPresets.json files

`fmt/core.h` not found

In a freshly create cmake-init project #include <fmt/core.h> throws a fatal error: file not found, see e.g. here.

However, in the CMakeLists.txt the existence fmt library is properly checked with find_package and also the target link is done properly by cmake-init.

The include is simple so this should not go wrong there.

What could possibly go wrong?

Again, thank you for your help 🍪

clang-tidy checks

I have not yet really used clang-tidy myself and I do not know what checks are widespread, so I would like to hear opinions about what checks should be included by default in the generated projects and what the config should look like.

clang-tidy integration available with 0.7.0

clang-format options

f325e68 introduced clang-format to the project, but instead of using one of the built-in styles, I rolled my own.

The goal of a format ruleset should be:

• consistency
• readability
• diff friendliness
• similarity to other languages (polyglot friendliness)

I hope what I created achieves that and if not, then feedback is welcome.

How to link additional libraries

I have initialized a C project "foobar" and made the following changes:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2e4e720..ea04ae4 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -53,6 +53,8 @@ target_include_directories(
     "$<BUILD_INTERFACE:${PROJECT_BINARY_DIR}/export>"
 )
 
+target_link_libraries(foobar_foobar PRIVATE m)
+
 target_compile_features(foobar_foobar PUBLIC c_std_11)
 
 # ---- Install rules ----
diff --git a/source/foobar.c b/source/foobar.c
index 362d5fe..c0bf09d 100644
--- a/source/foobar.c
+++ b/source/foobar.c
@@ -1,6 +1,8 @@
 #include "foobar/foobar.h"
+#define _USE_MATH_DEFINE
+#include <math.h>
 
 const char* exported_function()
 {
-  return "foobar";
+  return M_PI < 3. ? "foobar" : "palim";
 }

Obviously, my attempt is to link libm to the project but running

> cmake --preset=dev-unix
> cmake --build build/dev-unix

fails:

foobar/source/foobar.c:6:10: error: ‘M_PI’ undeclared (first use in this function)
    6 |   return M_PI < 3. ? "foobar" : "palim";
      |

Could you help me to fix this problem?

Thanks!

Thin mode

It was suggested on Reddit that cmake-init could have a thin mode where it outputs a more lean project. The problem with this is that projects are already pretty lean and I will not drop any amount of static analysis.

The only questionable part of a generated project is maybe the documentation, which is already in a questionable state. See #58

The other things are the markdown docs at the root of the project that instruct and help remind the user how to build the project, and makes it more or less ready to be published on GitHub and tick some boxes like license, CoC, contributing guide. The BUILDING.md also explains to users of that project how to build and use it, and other related information.
This maybe can go in a lean mode. (Maybe lean mode is more like a "private project" mode?)

I have already removed the OpenCppCoverage code on the dev branch, as it's a Windows specific program and it was always there only as an example. It can still be retrieved from the git history if one wishes to reference it.

More ideas are welcome.

Python packaging

The 0.26.0 and 0.26.1 releases on PyPI are broken, because of how the packaging is done.

8077df2 and 6421a7c added the template.py file to the release, however they were both released after the fact.

I should look into making the packaging simpler, so the imports are the same regardless of how this project is packaged (see the message of 6421a7c).

Tests

I think it would be nice if the project would allow one to choose between how it is now (without any framework) or use directly some framework.

I would suggest supporting Catch2 and GTest. Optionally also GMock and trompeloeil for mocking.
These have also special functions to use them in cmake, which is one of the reasons I would like them to see in such a template.

Another consideration would be the folder structure for tests. I've never seen a "source" or "src" folder in tests. What I often do is to add folders for the test types. Common is "unit_tests" and "integration_tests", but I guess that is far from a standard as well.
What would be considerable is an include folder I could imagine. I often use this for some "resuable" stuff like mock definitions. Again not sure how much standard that is.

Duplicate project name directories in installation include directory

Hello, is it intentional to duplicate the project name in the installation layout for the headers?

I see the following when installing the shared/static library (initialized with cmake-init -s /tmp/test-shared) example:

$ cmake --install build/dev --prefix prefix
-- Install configuration: "Debug"
-- Installing: /tmp/test-shared/prefix/include/test-shared
-- Installing: /tmp/test-shared/prefix/include/test-shared/test-shared
-- Installing: /tmp/test-shared/prefix/include/test-shared/test-shared/test-shared.hpp
-- Up-to-date: /tmp/test-shared/prefix/include/test-shared
-- Up-to-date: /tmp/test-shared/prefix/include/test-shared/test-shared
-- Installing: /tmp/test-shared/prefix/include/test-shared/test-shared/test-shared_export.hpp
-- Installing: /tmp/test-shared/prefix/lib/libtest-shared.a
-- Installing: /tmp/test-shared/prefix/share/test-shared/test-sharedConfig.cmake
-- Installing: /tmp/test-shared/prefix/share/test-shared/test-sharedConfigVersion.cmake
-- Installing: /tmp/test-shared/prefix/share/test-shared/test-sharedTargets.cmake
-- Installing: /tmp/test-shared/prefix/share/test-shared/test-sharedTargets-debug.cmake

Note the line here with duplicate test-shared/test-shared/ directories

-- Installing: /tmp/test-shared/prefix/include/test-shared/test-shared/test-shared.hpp

I would have expected it to read

-- Installing: /tmp/test-shared/prefix/include/test-shared/test-shared.hpp

which is a more compact directory layout while still maintaining directory isolation of the project headers.

I realize I can manually set -DCMAKE_INSTALL_INCLUDEDIR=include when configuring, but I think the expected behavior should be default for this initializer project.

I also realize that test-sharedTargets.cmake contains the following

set_target_properties(test-shared::test-shared PROPERTIES
  [...]
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/test-shared"
)

which means that an #include <test-shared/test-shared.hpp> still works from a CMake project that finds the library and uses the target with the duplicate project name directories in the include directory, but I still would have expected the include directory layout of the installation to be more compact by default, which would then make this snippet read INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include".

I believe the line(s) responsible for directory duplication are here and removal would produce the expected directory layout by default

cmake-init/cmake-init/templates/common/cmake/install-rules.cmake

Lines 1 to 3 in 44b8e24

	if(PROJECT_IS_TOP_LEVEL)
	set(CMAKE_INSTALL_INCLUDEDIR include/%(name)s CACHE PATH "")
	endif(){type header}

---

Unrelated: I'm not sure whether this kind of post belongs in the Issues or Discussions section, so apologies if this is posted in the wrong spot.

Spell and grammar checking

These are a form of static analysis and motivated by #79 I wish to further enhance this aspect of cmake-init.

Some additional tools were mentioned in #79 (comment) that might be used in addition to/instead of the existing codespell solution.

Run CI using CTest scripts

This is just an idea, but I like how check-type-align's CI looks. It could be worth considering using these in generated projects' CI.

cmake does not detect some vcpkg installed libraries when using cmake-init

I have created a sample project without cmake-init to test if vcpkg/cmakke/etc were working correctly.

With a CMakeLists.txt containing

cmake_minimum_required(VERSION 3.20)
project(fibo CXX)

find_package(fmt  REQUIRED)
find_package(range-v3  REQUIRED)

add_executable(fibo main.cpp)
target_compile_features(fibo PRIVATE cxx_std_17)

target_link_libraries(fibo
  PRIVATE
    fmt::fmt
    range-v3::range-v3)

everything works fine.

When I create a project with cmake-init, it stops being able to detect range-v3, but it does detect fmt.

environment:

cmake version 3.20.2
cmake-init version 0.31.2

steps to reproduce

1. create a cmake-init project, select vcpkg as the package manager
2. Open project in clion, and add "-DCMAKE_TOOLCHAIN_FILE=C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake" to the cmake profile.
3. add these lines to the generated CMakeLists.txt:

find_package(fmt  REQUIRED)
find_package(range-v3  REQUIRED)
target_link_libraries(cmtest_lib PRIVATE fmt::fmt range-v3::range-v3)

4. reset cmake cache and reload project

Result:

"C:\Program Files\JetBrains\CLion 2021.2.3\bin\cmake\win\bin\cmake.exe" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_DEPENDS_USE_COMPILER=FALSE -G "CodeBlocks - NMake Makefiles" C:\Users\Massiveatoms\Desktop\compsci\cmtest
-- Running vcpkg install
Detecting compiler hash for triplet x64-windows...
Detecting compiler hash for triplet x86-windows...
All requested packages are currently installed.
Restored 0 package(s) from C:\Users\Massiveatoms\AppData\Local\vcpkg\archives in 336.4 us. Use --debug to see more details.

Total elapsed time: 14.25 s

The package fmt provides CMake targets:

    find_package(fmt CONFIG REQUIRED)
    target_link_libraries(main PRIVATE fmt::fmt)

    # Or use the header-only version
    find_package(fmt CONFIG REQUIRED)
    target_link_libraries(main PRIVATE fmt::fmt-header-only)

-- Running vcpkg install - done
CMake Error at C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake:824 (_find_package):
  By not providing "Findrange-v3.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "range-v3",
  but CMake did not find one.

  Could not find a package configuration file provided by "range-v3" with any
  of the following names:

    range-v3Config.cmake
    range-v3-config.cmake

  Add the installation prefix of "range-v3" to CMAKE_PREFIX_PATH or set
  "range-v3_DIR" to a directory containing one of the above files.  If
  "range-v3" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  CMakeLists.txt:32 (find_package)


-- Configuring incomplete, errors occurred!
See also "C:/Users/Massiveatoms/Desktop/compsci/cmtest/cmake-build-debug/CMakeFiles/CMakeOutput.log".

[Failed to reload]

I have no idea what other information you need, so if you need further information, feel free to ask

Caching for Conan dependencies

I realised while writing #53 (comment) that Conan dependencies are not cached in CI.

The vcpkg template uses the friendlyanon/setup-vcpkg action, which handles vcpkg's binary cache automatically.

I'm tagging this issue as a question, because maybe this action could be provided by the Conan team itself.

The version of clang-tidy should be mentioned in the README

I have this error even though the file seems to be well formatted :

cmake -D FORMAT_COMMAND=clang-format-11 -P cmake/lint.cmake
  cmake -D FORMAT_COMMAND=clang-format-11 -P cmake/lint.cmake
  shell: /usr/bin/bash -e {0}
  env:
    pythonLocation: /opt/hostedtoolcache/Python/3.8.12/x64
    LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.8.12/x64/lib
The following files are badly formatted:

include/ThreadPool/ThreadPool.hpp

CMake Error at cmake/lint.cmake:51 (message):
  Run again with FIX=YES to fix these files.


Error: Process completed with exit code 1.

CI error: https://github.com/bensuperpc/ThreadPool/runs/4320815529?check_suite_focus=true#step:5:15

I have no errors with this command on Manjaro:
cmake -D FORMAT_COMMAND=clang-format-13 -P cmake/lint.cmake

The file appears to be formatted well with clang-format-13 (no changes):
clang-format-13 -style=file -i include/ThreadPool/ThreadPool.hpp

The file that causes concern: https://github.com/bensuperpc/ThreadPool/blob/master/include/ThreadPool/ThreadPool.hpp

Does having clang-format-13 change anything ?

Web cmake-init

Would a web version of cmake-init be of any use? Something similar to https://start.spring.io/

Some tools already require Python that generated projects offer integration with, so this is a really low priority issue in my book, especially since the Python code would need to be rewritten in JS.

CI uses VS2022, but an upgrade locally is not desired

Very easy solution: just add "generator": "Visual Studio 16 2019" to the dev-win64/dev preset in CMakeUserPresets.json.

If VS2019 is needed in CI as well, then you will have to downgrade the Windows image to windows-2019 and change the generator in the ci-win64 preset.

C++ modules

This issue is just for tracking the progress of modules.

At the moment, no generally available compiler seems to properly support modules.

CMake is also designing its API to properly integrate C++ modules: https://discourse.cmake.org/t/api-design-c-modules-source-listings-and-interface-properties/5389

Build failure on the dev branch

This issue is for tracking actions/runner-images#6091

There is another issue due to dependency upgrades, but I'll wait with pushing that until CI is fixed.

Building on MacOS

Hi, I got error CMAKE_MAKE_PROGRAM is not set.

My env is MacOS 11.3.1.

CMake version:

❯ cmake --version
cmake version 3.23.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Error in Root dir after cmake-init

❯ cmake --preset=dev
Preset CMake variables:

  BUILD_MCSS_DOCS="ON"
  CMAKE_BUILD_TYPE="Debug"
  CMAKE_CXX_CLANG_TIDY="clang-tidy;--header-filter=/Users/angel/Work/explore-cpp/idtaxes/*"
  CMAKE_CXX_CPPCHECK="cppcheck;--inline-suppr"
  CMAKE_CXX_EXTENSIONS="OFF"
  CMAKE_CXX_FLAGS="-Wall -Wextra -Wpedantic -Wconversion -Wsign-conversion -Wcast-qual -Wshadow -Wformat=2 -Wundef -Werror=float-equal"
  CMAKE_CXX_STANDARD="20"
  CMAKE_CXX_STANDARD_REQUIRED="ON"
  CMAKE_TOOLCHAIN_FILE="/scripts/buildsystems/vcpkg.cmake"
  VCPKG_MANIFEST_FEATURES="test"
  idtaxes_DEVELOPER_MODE="ON"

CMake Error at /Applications/CMake.app/Contents/share/cmake-3.23/Modules/CMakeDetermineSystem.cmake:130 (message):
  Could not find toolchain file: /scripts/buildsystems/vcpkg.cmake
Call Stack (most recent call first):
  CMakeLists.txt:9 (project)


CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
-- Configuring incomplete, errors occurred!

Can anyone help me?

Thank you

Update VS references to Visual Studio 2022

VS2022 is now generally available, however the windows-2022 workflow is still in beta and it's probably going to be a while until it becomes windows-latest.

This project will keep using VS2019 generator for CMake in the meantime, but it's trivial to update. Only the presets and the CI workflow need some editing.

Conan v2 usage

The generated build instructions and CI workflow aren't compatible with Conan v2.

Hoping @SpaceIm can chip in here with an example that shows how to use conanfile.txt with the new CMake generators.

[Feature Request] Turn off documentation with flag

First of all thanks for the amazing project :)
I have been using cmake-init for my project, and it has been working splendidly.

Would it be possible to get a flag for the generator that removes the docs (--no-docs) functionality (like --no-clang-tidy).
I think it has a couple of benefits if the user. The user might want to roll their own documentation / github wiki etc. Furthermore it would reduce code/files for small simple projects.

I hope it would not be too cumbersome :)

Add (more) support code for IDEs (VS, Xcode)

The gif_engine example project has such support code:

• Add headers to targets so they show up in solution view (ref)
• Use source_group to make solution view not flatten the files (ref)
• Add startup target, so by default people can debug right away conveniently (ref)

The folders.cmake is already IDE specific support code. The example project uses the target_sources_grouped command to combine target_sources and source_group, so files don't have to be mentioned twice or added to a list, which makes use more declarative. This is a command would have to be used on the main code path as well, which could make reading the project CML more difficult.

`sanitize` job fails in new project

First: cmake-init is amazing - thanks for this! ❤️

Now to my question: In my freshly initialized project the Install dependencies step in the sanitize job fails in the CI, see the log below.

Can you help me fixing this? Locally (macOS 12.6.2) I got it running when I changed the compiler.libcxx in the .github/clang-14.profile to libc++, but this does not fix the failing build in the CI.

Help is appreciated, thanks a lot!

Run pip3 install "conan<2" && conan profile new default && cp .github/clang-14.profile "$(conan config home)/profiles/default" && conan install . -b missing [11](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:12) Collecting conan<2 [12](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:13) Downloading conan-1.56.0.tar.gz (777 kB) [13](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:14) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 777.6/777.6 kB 6.8 MB/s eta 0:00:00 [14](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:15) Preparing metadata (setup.py): started [15](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:16) Preparing metadata (setup.py): finished with status 'done' [16](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:17) Collecting requests<3.0.0,>=2.25 [17](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:18) Downloading requests-2.28.1-py3-none-any.whl (62 kB) [18](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:19) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 62.8/62.8 kB 14.5 MB/s eta 0:00:00 [19](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:20) Collecting urllib3<1.27,>=1.26.6 [20](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:21) Downloading urllib3-1.26.13-py2.py3-none-any.whl (140 kB) [21](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:22) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 140.6/140.6 kB 10.7 MB/s eta 0:00:00 [22](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:23) Collecting colorama<0.5.0,>=0.3.3 [23](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:24) Downloading colorama-0.4.6-py2.py3-none-any.whl (25 kB) [24](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:25) Collecting PyYAML<=6.0,>=3.11 [25](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:26) Downloading PyYAML-6.0-cp38-cp38-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl (701 kB) [26](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:27) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 701.2/701.2 kB 12.7 MB/s eta 0:00:00 [27](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:28) Collecting patch-ng<1.18,>=1.17.4 [28](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:29) Downloading patch-ng-1.17.4.tar.gz (17 kB) [29](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:30) Preparing metadata (setup.py): started [30](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:31) Preparing metadata (setup.py): finished with status 'done' [31](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:32) Collecting fasteners>=0.14.1 [32](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:33) Downloading fasteners-0.18-py3-none-any.whl (18 kB) [33](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:34) Collecting six<=1.16.0,>=1.10.0 [34](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:35) Downloading six-1.16.0-py2.py3-none-any.whl (11 kB) [35](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:36) Collecting node-semver==0.6.1 [36](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:37) Downloading node_semver-0.6.1-py3-none-any.whl (10 kB) [37](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:38) Collecting pygments<3.0,>=2.0 [38](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:39) Downloading Pygments-2.14.0-py3-none-any.whl (1.1 MB) [39](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:40) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 15.8 MB/s eta 0:00:00 [40](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:41) Collecting tqdm<5,>=4.28.1 [41](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:42) Downloading tqdm-4.64.1-py2.py3-none-any.whl (78 kB) [42](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:43) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 78.5/78.5 kB 21.7 MB/s eta 0:00:00 [43](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:44) Collecting python-dateutil<3,>=2.7.0 [44](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:45) Downloading python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB) [45](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:46) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 247.7/247.7 kB 17.5 MB/s eta 0:00:00 [46](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:47) Collecting bottle<0.13,>=0.12.8 [47](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:48) Downloading bottle-0.12.23-py3-none-any.whl (90 kB) [48](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:49) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 90.1/90.1 kB 26.1 MB/s eta 0:00:00 [49](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:50) Collecting pluginbase>=0.5 [50](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:51) Downloading pluginbase-1.0.1.tar.gz (43 kB) [51](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:52) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 43.6/43.6 kB 14.0 MB/s eta 0:00:00 [52](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:53) Preparing metadata (setup.py): started [53](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:54) Preparing metadata (setup.py): finished with status 'done' [54](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:55) Collecting PyJWT<3.0.0,>=2.4.0 [55](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:56) Downloading PyJWT-2.6.0-py3-none-any.whl (20 kB) [56](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:57) Collecting Jinja2<4.0.0,>=3.0 [57](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:58) Downloading Jinja2-3.1.2-py3-none-any.whl (133 kB) [58](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:59) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 133.1/133.1 kB 23.5 MB/s eta 0:00:00 [59](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:60) Collecting distro<=1.7.0,>=1.0.2 [60](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:61) Downloading distro-1.7.0-py3-none-any.whl (20 kB) [61](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:62) Collecting MarkupSafe>=2.0 [62](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:63) Downloading MarkupSafe-2.1.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (25 kB) [63](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:64) Collecting certifi>=2017.4.17 [64](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:65) Downloading certifi-2022.12.7-py3-none-any.whl (155 kB) [65](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:66) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 155.3/155.3 kB 24.6 MB/s eta 0:00:00 [66](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:67) Collecting idna<4,>=2.5 [67](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:68) Downloading idna-3.4-py3-none-any.whl (61 kB) [68](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:69) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.5/61.5 kB 22.4 MB/s eta 0:00:00 [69](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:70) Collecting charset-normalizer<3,>=2 [70](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:71) Downloading charset_normalizer-2.1.1-py3-none-any.whl (39 kB) [71](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:72) Installing collected packages: pluginbase, patch-ng, node-semver, bottle, urllib3, tqdm, six, PyYAML, PyJWT, pygments, MarkupSafe, idna, fasteners, distro, colorama, charset-normalizer, certifi, requests, python-dateutil, Jinja2, conan [72](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:73) DEPRECATION: pluginbase is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559 [73](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:74) Running setup.py install for pluginbase: started [74](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:75) Running setup.py install for pluginbase: finished with status 'done' [75](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:76) DEPRECATION: patch-ng is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559 [76](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:77) Running setup.py install for patch-ng: started [77](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:78) Running setup.py install for patch-ng: finished with status 'done' [78](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:79) DEPRECATION: conan is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559 [79](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:80) Running setup.py install for conan: started [80](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:81) Running setup.py install for conan: finished with status 'done' [81](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:82) Successfully installed Jinja2-3.1.2 MarkupSafe-2.1.1 PyJWT-2.6.0 PyYAML-6.0 bottle-0.12.23 certifi-2022.12.7 charset-normalizer-2.1.1 colorama-0.4.6 conan-1.56.0 distro-1.7.0 fasteners-0.18 idna-3.4 node-semver-0.6.1 patch-ng-1.17.4 pluginbase-1.0.1 pygments-2.14.0 python-dateutil-2.8.2 requests-2.28.1 six-1.16.0 tqdm-4.64.1 urllib3-1.26.13 [82](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:83) Empty profile created: /home/runner/.conan/profiles/default [83](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:84) Configuration: [84](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:85) [settings] [85](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:86) arch=x86_64 [86](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:87) build_type=Release [87](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:88) compiler=clang [88](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:89) compiler.libcxx=libc++ [89](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:90) compiler.version=14 [90](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:91) os=Linux [91](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:92) [options] [92](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:93) [build_requires] [93](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:94) [env] [94](https://github.com/krahlos/argparseplusplus/actions/runs/3839862625/jobs/6538205634#step:4:95)

95
fmt/9.1.0: Not found in local cache, looking in remotes...
96
fmt/9.1.0: Trying with 'conancenter'...
97
Downloading conanmanifest.txt
98
Downloading conanfile.py
99
Downloading conan_export.tgz
100
fmt/9.1.0: Downloaded recipe revision 0
101
catch2/3.1.0: Not found in local cache, looking in remotes...
102
catch2/3.1.0: Trying with 'conancenter'...
103
Downloading conanmanifest.txt
104
Downloading conanfile.py
105
Downloading conan_export.tgz
106
catch2/3.1.0: Downloaded recipe revision 0
107
conanfile.py: Installing package
108
Requirements
109
fmt/9.1.0 from 'conancenter' - Downloaded
110
Packages
111
fmt/9.1.0:6735d08437240945297d1fd41b3098defba4e31f - Build
112
Build requirements
113
catch2/3.1.0 from 'conancenter' - Downloaded
114
Build requirements packages
115
catch2/3.1.0:02c5f63e68c8503a47598ccd752484d0f5b7e58b - Build
116

117
Installing (downloading, building) binaries...
118
Downloading conan_sources.tgz
119
catch2/3.1.0: Configuring sources in /home/runner/.conan/data/catch2/3.1.0///source/src
120
catch2/3.1.0:
121
catch2/3.1.0: Copying sources to build folder
122
catch2/3.1.0: Building your package in /home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b
123
catch2/3.1.0: Generator txt created conanbuildinfo.txt
124
catch2/3.1.0: Calling generate()
125
catch2/3.1.0: Preset 'release' added to CMakePresets.json. Invoke it manually using 'cmake --preset release'
126
catch2/3.1.0: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/generators/conan_toolchain.cmake -DCATCH_INSTALL_DOCS=OFF -DCATCH_INSTALL_EXTRAS=ON -DCATCH_DEVELOPMENT_BUILD=OFF -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release'
127
catch2/3.1.0: Aggregating env generators
128
catch2/3.1.0: Calling build()
129
catch2/3.1.0: Apply patch (portability): Install dll in bin folder
130
catch2/3.1.0: Apply patch (portability): Fix import of global symbols for msvc shared
131
catch2/3.1.0: CMake command: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/runner/.conan/data/catch2/3.1.0///package/02c5f63e68c8503a47598ccd752484d0f5b7e58b" -DCATCH_INSTALL_DOCS="OFF" -DCATCH_INSTALL_EXTRAS="ON" -DCATCH_DEVELOPMENT_BUILD="OFF" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/src"
132
-- Using Conan toolchain: /home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/generators/conan_toolchain.cmake
133
-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC)
134
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
135
-- The CXX compiler identification is GNU 11.3.0
136
-- Detecting CXX compiler ABI info
137
-- Detecting CXX compiler ABI info - failed
138
-- Check for working CXX compiler: /usr/bin/c++
139
-- Check for working CXX compiler: /usr/bin/c++ - broken
140
CMake Error at /usr/local/share/cmake-3.25/Modules/CMakeTestCXXCompiler.cmake:63 (message):
141
The C++ compiler
142

143
"/usr/bin/c++"
144

145
is not able to compile a simple test program.
146

147
It fails with the following output:
148

149
Change Dir: /home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/Release/CMakeFiles/CMakeScratch/TryCompile-wNY3t1
150

151
Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_a7dc3/fast && /usr/bin/gmake -f CMakeFiles/cmTC_a7dc3.dir/build.make CMakeFiles/cmTC_a7dc3.dir/build
152
gmake[1]: Entering directory '/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/Release/CMakeFiles/CMakeScratch/TryCompile-wNY3t1'
153
Building CXX object CMakeFiles/cmTC_a7dc3.dir/testCXXCompiler.cxx.o
154
/usr/bin/c++ -m64 -stdlib=libc++ -fPIE -o CMakeFiles/cmTC_a7dc3.dir/testCXXCompiler.cxx.o -c /home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/Release/CMakeFiles/CMakeScratch/TryCompile-wNY3t1/testCXXCompiler.cxx
155
c++: error: unrecognized command-line option ‘-stdlib=libc++’
156
gmake[1]: *** [CMakeFiles/cmTC_a7dc3.dir/build.make:78: CMakeFiles/cmTC_a7dc3.dir/testCXXCompiler.cxx.o] Error 1
157
gmake[1]: Leaving directory '/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/Release/CMakeFiles/CMakeScratch/TryCompile-wNY3t1'
158
gmake: *** [Makefile:127: cmTC_a7dc3/fast] Error 2
159

160

161

162

163

164
CMake will not be able to correctly generate this project.
165
Call Stack (most recent call first):
166
CMakeLists.txt:39 (project)
167

168

169
-- Configuring incomplete, errors occurred!
170
See also "/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/Release/CMakeFiles/CMakeOutput.log".
171
See also "/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/Release/CMakeFiles/CMakeError.log".
172
catch2/3.1.0:
173
WARN: Remotes registry file missing, creating default one in /home/runner/.conan/remotes.json
174
catch2/3.1.0: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
175
catch2/3.1.0: ERROR: Package '02c5f63e68c8503a47598ccd752484d0f5b7e58b' build failed
176
catch2/3.1.0: WARN: Build folder /home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/Release
177
ERROR: catch2/3.1.0: Error in build() method, line 109
178
cmake.configure()
179
ConanException: Error 1 while executing cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/build/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/runner/.conan/data/catch2/3.1.0///package/02c5f63e68c8503a47598ccd752484d0f5b7e58b" -DCATCH_INSTALL_DOCS="OFF" -DCATCH_INSTALL_EXTRAS="ON" -DCATCH_DEVELOPMENT_BUILD="OFF" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/runner/.conan/data/catch2/3.1.0///build/02c5f63e68c8503a47598ccd752484d0f5b7e58b/src"
180
Error: Process completed with exit code 1.

HP-UX and other platforms with older CMake distributions

HP-UX in particular cannot use CMake >= 3.10, because of a missing C++11 compiler. (ref)

Things that need to be removed/changed in a generated project to accomodate older CMake versions:

• Omitting the DESTINATION arguments for install(TARGETS) was added in CMake 3.14.
  • Solution is to use the older form of the install(TARGETS) command with explicit destinations set. See the NAME LINK section of this example's README for the version you target. The code in the cmake-3.8 branch works for any older version, the command only changed in 3.12 and 3.14.
• The ARCH_INDEPENDENT argument (useful mainly for header-only libraries) for the write_basic_package_version_file command was added in CMake 3.14.
  • The CMAKE_SIZEOF_VOID_P variable needs to be temporarily unset for the command call.
• The documentation code (only available in dev mode) uses FetchContent (added in CMake 3.11) and the FetchContent_MakeAvailable command (added in CMake 3.14.
  • Since this only affects development, this isn't that much of an issue, because both the dev mode and BUILD_MCSS_DOCS variables need to be enabled to hit this code path. Depending on your needs, you can either add a version check around the docs code (if(CMAKE_VERSION VERSION_GREATER "3.13")) or entirely remove it.
• Compile features to select a specific standard level was added in CMake 3.8.
  • Selecting a language level can still sort of be emulated with using the concrete features like cxx_binary_literals or c_function_prototypes. Please note that older CMake versions are not aware of newer C++ and C standards, so check the docs of the CMake version you wish to use as a minimum for support.

Everything else relates to docs:

• cmake itself can't use presets prior to CMake 3.19, so the documentation should mention that.
  • Note that the CMake docs discourage tools invoking CMake with --preset, so there could still be editors/IDEs that can make use of them.
• The -S and -B flags were added in CMake 3.13. Prior versions required you navigating to the binary directory and invoking cmake with the source directory without a flag.
• --install was added in CMake 3.15.

Header install path has a redundant component

After installing the default header-only project, the end-user would include the header like this:

#include <header-only/header-only/header-only.hpp>

Is that intentional? I would guess most maintainers would want to delete one of those path components,

modified   cmake/install-rules.cmake
@@ -1,5 +1,5 @@
 if(PROJECT_IS_TOP_LEVEL)
-  set(CMAKE_INSTALL_INCLUDEDIR include/header-only CACHE PATH "")
+  set(CMAKE_INSTALL_INCLUDEDIR include CACHE PATH "")
 endif()
 
 # Project is configured with no languages, so tell GNUInstallDirs the lib dir

Raise CMake requirement

Right now, people consuming projects generated with cmake-init are required to have at least CMake 3.14 installed and developers developing those projects are recommended to have at least 3.20 installed to make use of presets.

Group	Minimum CMake version	Reason
Consumers	3.14	install(TARGETS) uses the correct cross-platform paths when omitted FetchContent is more convenient to use Improvements from earlier versions
Consumers	3.xx	C++23 template with import std; available See #55 for tracking modules Improvements from earlier versions
Developers	3.20	Presets version 2 (enables users with VSCode's "CMake Tools" extension) Build and tests presets simplify command line workflow ctest --test-dir to run tests from anywhere Improvements from earlier versions

Contribution Guidelines

As I said in the other project, I feel like a cmake init script is something we really needed and this is quite a good start!

I do see the problem though that cmake is quite opinion based in many ways. Obviously there are some best practices like use targets everywhere. But there are a lot of things, which are discussable or completly based on preference.
So two common acceptable options would be:

• Make it configurable
• Don't do it if it's controversial

The first option is great for many things, but making everything configurable can be too much at some point. You don't wanna go through a 2h init setup questions neither is it something you wanna maintain I suppose.
So just asking for important stuff like you do now seems good to me.

Just not doing controversial things isn't the worst thing either. At some point it's good to not implement too much, which 80% don't agree with.

But I see some points that are controversial, a pain in the ass to make too configurable, but relevant to a lot of people. One of these is probably dependency management. There are a few options, which one could make configurable. But for all the methods there are also a few ways you could do it.

So I want to propose a general mechanism to deal with this thing. For things that are important and need a decision, just decide. But open up an issue where people can discuss about it. And then document why in particular you made decision xyz and how people could tweak it perhaps, if it doesn't fit for them. This way we have sort of "best practices" and also document them.
In such starter templates I often wonder if there is any rationale behind some certain things. At least for more complex stuff.

An example: Say we add support for a testing framework (GTest) and allow one to use find_package or FetchContent for it (or CPM .. or git submodule or ...).
Say then we want to add the FetchContent part ... how would you do it? Where put the call? When call FetchContent ... when MakeAvailble?
There are a few options here.

One good approach is creating a "dependencies" folder, then list all FetchContent() Calls and then make a folder for each dependency and put in there each MakeAvailable Call. This is one of many approaches, a good one I would say. For a lot of users it might be super confusing why anyone would do it like this.
There are a few reasons here:

• Putting it in a subdirectory leads to a clean separation (every seen this huge single root Cmake Files?)
• Listing all FetchContent Calls first is more efficient in case dependencies share dependencies. Also allows to overwrite a few things
• Putting all MakeAvailable Calls in a new file / folder puts them in a new scope. Therefore variables can be set just for that particular project. For example say you need LIB XYZ as shared, put a set(BUILD_SHARED_LIBS ON) before ... works and doesn't affect anything else
  ...

It doesn't mean this is the perfect or only approach. But I think it's better to include something than nothing, especially if a lot of people need it. But without any explanation it would be weird for a lot of people. And perhaps this is also something not one person alone should decide, at least not if the overall goal is to make this the "agreed best practice init script".

So a discussion issue + documentation on the decision (with perhaps background information) for all these things would help a lot I would say.

How to deal with C4251 warning

https://stackoverflow.com/a/22054743 gives a good summary for possible remedies.

PIMPL seems to be the best option, but is that really a good concept to have in an init script targeting mainly beginners?
Need to think about this.

Directory structure

Hi,

I wonder what the choice was for the directory names. Does this follow a standard?

Especially source is something I never saw before, I only know it as src. I personally would also prefer tests instead of test

--std flag not working

From a fresh install, all attempts to use the --std flag are failing

$ uname -a
Linux user 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul 20 2021 x86_64 x86_64 x86_64 GNU/Linux

$ pip install --user cmake-init
...
Successfully installed cmake-init-0.20.4

$ cmake-init -h .
...
You are all set. Have fun programming and create something awesome!

$ cmake-init -h --std c++17 .
Traceback (most recent call last):
  File "/home/user/.local/bin/cmake-init", line 8, in <module>
    sys.exit(pypi_main())
  File "/home/user/.local/lib/python3.8/site-packages/cmake_init_lib/__init__.py", line 14, in pypi_main
    main(zip)
  File "/home/user/.local/lib/python3.8/site-packages/cmake_init_lib/cmake_init.py", line 489, in main
    create(args, zip)
  File "/home/user/.local/lib/python3.8/site-packages/cmake_init_lib/cmake_init.py", line 299, in create
    d = get_substitutes(args, os.path.basename(path))
  File "/home/user/.local/lib/python3.8/site-packages/cmake_init_lib/cmake_init.py", line 133, in get_substitutes
    "std": ask(
  File "/home/user/.local/lib/python3.8/site-packages/cmake_init_lib/cmake_init.py", line 83, in ask
    return prompt(*args, **kwargs, no_prompt=no_prompt)
  File "/home/user/.local/lib/python3.8/site-packages/cmake_init_lib/cmake_init.py", line 61, in prompt
    raise ValueError()
ValueError

Alternative to Doxygen

As Doxygen doesn't quite work as well as one would hope ([1]), it might be time to look into alternatives.

One candidate so far is https://github.com/hdoc/hdoc

Doxygen 1.9 can't be used to run `docs`

Because of m.css not having still support for Doxygen 1.9 the cmake --build --preset=dev -t docs fails with a weird message, maybe adding a detailed error saying to downgrade Doxygen to 1.8 or switching to another frontend that supports doxygen 1.9

Not Compatible with Conan 1.51.x

Environment:
Platform: Mac mini (M1, 2020)
OS: macOS 12.4
CMake version: 3.24.0
cmake-init version: 0.31.2
conan version: 1.51.2

If I use Conan 1.50.2, it works.

error message for cmake-init with Conan 1.51.2:
$ cmake --preset=dev

-- Using Conan toolchain: /Users/xanaduw/tmp/greatness/conan/conan_toolchain.cmake
-- Conan: Component target declared 'fmt::fmt'
CMake Error (dev) at conan/fmt-Target-debug.cmake:5 (set):
uninitialized variable 'fmt_COMPILE_OPTIONS_CXX_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:5 (set):
uninitialized variable 'fmt_COMPILE_OPTIONS_C_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:9 (set):
uninitialized variable 'fmt_SHARED_LINK_FLAGS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:9 (set):
uninitialized variable 'fmt_SHARED_LINK_FLAGS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:9 (set):
uninitialized variable 'fmt_EXE_LINK_FLAGS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:15 (conan_find_apple_frameworks):
uninitialized variable 'fmt_FRAMEWORKS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:15 (conan_find_apple_frameworks): [155/1907]
uninitialized variable 'fmt_FRAMEWORK_DIRS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:25 (set_property):
uninitialized variable 'fmt_SYSTEM_LIBS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:34 (conan_package_library_targets):
uninitialized variable 'fmt_LIBS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:34 (conan_package_library_targets):
uninitialized variable 'fmt_LIB_DIRS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:42 (set):
uninitialized variable 'fmt_BUILD_DIRS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-Target-debug.cmake:43 (set):
uninitialized variable 'fmt_BUILD_DIRS_DEBUG'
Call Stack (most recent call first):
conan/fmtTargets.cmake:26 (include)
conan/fmt-config.cmake:10 (include)
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-config.cmake:23 (set): [107/1907]
uninitialized variable 'fmt_INCLUDE_DIRS_DEBUG'
Call Stack (most recent call first):
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-config.cmake:24 (set):
uninitialized variable 'fmt_INCLUDE_DIRS_DEBUG'
Call Stack (most recent call first):
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/fmt-config.cmake:26 (set):
uninitialized variable 'fmt_DEFINITIONS_DEBUG'
Call Stack (most recent call first):
CMakeLists.txt:31 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

-- Conan: Component target declared 'Catch2::Catch2'
-- Conan: Component target declared 'Catch2::Catch2WithMain'
CMake Error (dev) at conan/Catch2-Target-debug.cmake:5 (set):
uninitialized variable 'catch2_COMPILE_OPTIONS_CXX_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.
CMake Error (dev) at conan/Catch2-Target-debug.cmake:5 (set):
uninitialized variable 'catch2_COMPILE_OPTIONS_C_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:9 (set):
uninitialized variable 'catch2_SHARED_LINK_FLAGS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:9 (set):
uninitialized variable 'catch2_SHARED_LINK_FLAGS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:9 (set):
uninitialized variable 'catch2_EXE_LINK_FLAGS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:15 (conan_find_apple_frameworks):
uninitialized variable 'catch2_FRAMEWORKS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:15 (conan_find_apple_frameworks):
uninitialized variable 'catch2_FRAMEWORK_DIRS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:25 (set_property):
uninitialized variable 'catch2_SYSTEM_LIBS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:34 (conan_package_library_targets):
uninitialized variable 'catch2_LIBS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:34 (conan_package_library_targets):
uninitialized variable 'catch2_LIB_DIRS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:42 (set):
uninitialized variable 'catch2_BUILD_DIRS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2-Target-debug.cmake:43 (set):
uninitialized variable 'catch2_BUILD_DIRS_DEBUG'
Call Stack (most recent call first):
conan/Catch2Targets.cmake:26 (include)
conan/Catch2Config.cmake:10 (include)
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2Config.cmake:23 (set):
uninitialized variable 'catch2_INCLUDE_DIRS_DEBUG'
Call Stack (most recent call first):
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2Config.cmake:24 (set):
uninitialized variable 'catch2_INCLUDE_DIRS_DEBUG'
Call Stack (most recent call first):
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

CMake Error (dev) at conan/Catch2Config.cmake:26 (set):
uninitialized variable 'catch2_DEFINITIONS_DEBUG'
Call Stack (most recent call first):
test/CMakeLists.txt:9 (find_package)
This error is for project developers. Use -Wno-error=dev to suppress it.

Make build directory compatible with `find_package`

Hello! First, thank you for the wonderful project! This is a great reference for modern and essential CMake practices.

I am wondering whether it would be useful to have the build directory be compatible with find_package. With the changes, a user would be able to find and use the targets of this project from the build directory instead of requiring installation.

Not requiring installation can help to reduce the development cycle if this project is being actively developed to support features of the project depending on this project.

As a motivating concrete example, using the test directory since it's also a standalone project, a user would be able to do the following:

cmake-init /tmp/shared -s

cd /tmp/shared
cmake --preset=dev
cmake --build --preset=dev

cmake -S /tmp/shared/test \
  -B /tmp/shared/test/build \
  -Dshared_DIR=/tmp/shared/build/dev
cmake --build /tmp/shared/test/build
ctest --test-dir /tmp/shared/test/build

Notice that the installation command is not executed.

I have a working branch (feature/export-build-dir) in my fork, but I wanted to check here first to see whether a PR would have a chance of acceptance. The branch uses CMake's export and configure_package_config_file to achieve this.

Thank you!

m.css for C projects

Since 85cff27, the version of m.css is a slightly patched version with some fixes included, however m.css is mainly for C++ projects.

What'd be a good alternative for C projects?

Simplify executable install rules

The current install rules for executables exports a CMake package for executables. This is rarely useful, mostly for interpreters and build tools, things that ought to be run during CMake configure.

Removing this would make the install rules much simpler and for those who still need something like that can just check the history of https://github.com/friendlyanon/cmake-init-executable.

Windows SDK requirement

Some Windows SDKs (10.0.17763.0 and earlier?) have bugs in them that emit warnings with the new, standards conforming preprocessor (/Zc:preprocessor). The SDK can be specified by setting the system version for CMake (as is done in a6683d5), but this has potential issues.

Windows developers using this script locally will also have to install a Windows Update newer than 10.0.17763 with the matching Windows SDK to get the correct behavior by default.

This might be too much of a mental overhead for someone just starting out. Should the preprocessor flag be dropped and instead the ubuntu and macos CI runs be used to verify the conformance of the code?

`#include ""` vs `#include <>`

#include <> will always look in directories the specified for the target or the system location(s), while #include "" will also look on the filesystem relative to the file before that.

This extra work incurs some cost, however the ability to group includes differently using clang-format is useful.

Doesn't work on Windows due to .bat using current directory when invoked to try to find .pyz

rayga@DESKTOP-88A51E5 MINGW64 ~/Projects/tmp/reaper-direct-loader
$ cmake-init.bat -e ./
python: can't open file 'C:\Users\rayga\Projects\tmp\reaper-direct-loader\cmake-init.pyz': [Errno 2] No such file or directory

Slowdown gif in the main readme

Currently, gif in the main readme played incredibly fast. There is a lot of text there, interesting text that advertised the library, but I can't read it because of the speed. It seems it needs a 5-10x slowdown to be useful.

Could not read presets: Unrecognized "version" field

I've followed the instructions exactly, using cmake-init v0.24.0. But when I do cd cpptest && cmake --preset=dev, I only get the error:

CMake Error: Could not read presets from 
C:/Users/Felix Schütt/Development/cpptest: Unrecognized "version" field

I've uploaded the code generated by cmake-init here for debugging: https://github.com/fschutt/cpptest

cmake 3.19.1
cmake-init 0.24.0
Windows 8.1
clang 12.0.0
target: x86_64-pc-windows-msvc

Invalid workflow file generated by cmake-init

I have set up the project using cmake-init with vcpkg. I made an initial commit after the generation of code but GitHub reported that ci.yml generated has syntax error near the vcpkg installation step.

The file generated is here:
https://pastebin.com/gQTA8p43

And the error reported by GitHub action is near line 55:

I did a check on the yaml syntax and think it has no issue. Can someone help me out with this?

Python packaging

zipapp is used to create a self-contained runnable artifact, but I'm not sure if this is the best way to go about things.

This hack is also not something I like to see in the code, but after local testing, this is the only thing that stopped Python from closing the file handle to the zip.

Minimal boilerplate for Conan and vcpkg (now in preview)

I am thinking of adding a -p flag for package manager biolerplate. C++ projects would be importing the fmt library, I'll have to thing about what to import for C projects.