Giter Site home page Giter Site logo

cmake_template's Introduction

cmake_template

ci codecov CodeQL

About cmake_template

This is a C++ Best Practices GitHub template for getting up and running with C++ quickly.

By default (collectively known as ENABLE_DEVELOPER_MODE)

  • Address Sanitizer and Undefined Behavior Sanitizer enabled where possible
  • Warnings as errors
  • clang-tidy and cppcheck static analysis
  • CPM for dependencies

It includes

  • a basic CLI example
  • examples for fuzz, unit, and constexpr testing
  • large GitHub action testing matrix

It requires

  • cmake
  • a compiler

This project gets you started with a simple example of using FTXUI, which happens to also be a game.

Getting Started

Use the GitHub template

First, click the green Use this template button near the top of this page. This will take you to GitHub's 'Generate Repository' page. Fill in a repository name and short description, and click 'Create repository from template'. This will allow you to create a new repository in your GitHub account, prepopulated with the contents of this project.

After creating the project please wait until the cleanup workflow has finished setting up your project and committed the changes.

Now you can clone the project locally and get to work!

git clone https://github.com/<user>/<your_new_repo>.git

More Details

Testing

See Catch2 tutorial

Fuzz testing

See libFuzzer Tutorial

cmake_template's People

Contributors

adrian5 avatar aminya avatar arnemertz avatar avitase avatar caellian avatar clausklein avatar ddalcino avatar developerpaul123 avatar dk949 avatar hadrabap avatar jason5480 avatar jmarrec avatar keenpaul29 avatar lefticus avatar ltdsauce avatar madduci avatar michael137 avatar mo-xiaoming avatar novasmoof avatar patrickelectric avatar paulbendixen avatar prateek avatar ralphsteinhagen avatar saimen avatar sleepingwell avatar st0wy avatar toppdev avatar valerioformato avatar viniciusferrao avatar vittorioromeo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cmake_template's Issues

Creating repo with repo name containing '-' using ftxui_template breaks code

In ftxui_template, repository name is used for changing project name in CMakeLists.txt, configured_files/config.hpp.in, src/main.cpp files. template_janitor.yml is literally replaces namespace name to repo name. If repo name contains hypens or any other characters which are not allowed as part of identifiers. it breaks the code.
Please add a note regarding this issue, this will save time for people, Thank you.

Linker.cmake should use target_link_options instead of target_compile_options

target_compile_options(${project_name} INTERFACE ${LINKER_FLAG})

From my understanding target_compile_options can be replaced by the more appropriate target_link_options.

Motivation

Functionally there's no difference, but adding linker-specific flags to the compilation step will raise warnings e.g. clang: error: argument unused during compilation: '-fuse-ld=mold' [-Werror,-Wunused-command-line-argument] in certain setups.

Example from CI in a project of mine. Treating warnings as errors means this harmless warning caused CI to fail.

Using target_link_options resolved it.

Thank you for sharing and maintaining this template project, it is a tremendous help!

Build Failed: Missing include in ftxui code

FAILED: _deps/ftxui-build/CMakeFiles/screen.dir/src/ftxui/screen/string.cpp.o 
/usr/bin/g++-13  -I/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/src -I/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -fcf-protection -fstack-clash-protection  -D_GLIBCXX_ASSERTIONS -g -std=c++20 -flto=auto -fno-fat-lto-objects -Wall -Werror -Wextra -Wcast-align -Wdeprecated -Wmissing-declarations -Wnon-virtual-dtor -Wnull-dereference -Woverloaded-virtual -Wpedantic -Wshadow -Wunused -MD -MT _deps/ftxui-build/CMakeFiles/screen.dir/src/ftxui/screen/string.cpp.o -MF _deps/ftxui-build/CMakeFiles/screen.dir/src/ftxui/screen/string.cpp.o.d -o _deps/ftxui-build/CMakeFiles/screen.dir/src/ftxui/screen/string.cpp.o -c /builds/ClausKlein/cmake_template/build/_deps/ftxui-src/src/ftxui/screen/string.cpp
In file included from /builds/ClausKlein/cmake_template/build/_deps/ftxui-src/src/ftxui/screen/string.cpp:8:
/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/include/ftxui/screen/string.hpp:51:48: error: 'uint32_t' was not declared in this scope
   51 | WordBreakProperty CodepointToWordBreakProperty(uint32_t codepoint);
      |                                                ^~~~~~~~
/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/include/ftxui/screen/string.hpp:7:1: note: 'uint32_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
    6 | #include <vector>    // for vector
  +++ |+#include <cstdint>
    7 | 
/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/src/ftxui/screen/string.cpp: In function 'bool {anonymous}::IsCombining(uint32_t)':
/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/src/ftxui/screen/string.cpp:1415:45: error: 'ftxui::CodepointToWordBreakProperty' cannot be used as a function
 1415 |   return ftxui::CodepointToWordBreakProperty(ucs) == WBP::Extend;
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/src/ftxui/screen/string.cpp: At global scope:
/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/src/ftxui/screen/string.cpp:1570:66: error: 'ftxui::WordBreakProperty ftxui::CodepointToWordBreakProperty(uint32_t)' redeclared as different kind of entity
 1570 | WordBreakProperty CodepointToWordBreakProperty(uint32_t codepoint) {
      |                                                                  ^
/builds/ClausKlein/cmake_template/build/_deps/ftxui-src/include/ftxui/screen/string.hpp:51:19: note: previous declaration 'ftxui::WordBreakProperty ftxui::CodepointToWordBreakProperty'
   51 | WordBreakProperty CodepointToWordBreakProperty(uint32_t codepoint);
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
[121/196] Building CXX object _deps/ftxui-build/CMakeFiles/screen.dir/src/ftxui/screen/terminal.cpp.o
[122/196] Building CXX object _deps/ftxui-build/CMakeFiles/screen.dir/src/ftxui/screen/screen.cpp.o
ninja: build stopped: subcommand failed.

Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1

see gitlab MR 1

Add Contributions guidelines

I found a tiny issue in the repo and put up a PR to address: #48

As I was doing so, it wasn't clear to me if there were any guidelines the maintainers wanted me to follow. Even a simple ("feel free to open a PR") would be better than nothing.

GH recommendations for this kinda thing if you wanna put something a little more standardized down: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

Documentation on how to use Doxygen?

Hello, is there's any documentation on how to use Doxygen? I see that cmake/Doxygen.cmake is shipped but I can't find any instructions on how to use it correctly in the project.

Some suggestions about devcontainer.json, clang-tidy, cmake-format, and ubuntu jimmy.

Hello @lefticus. I admire your work. I have some suggestions and we can discuss about them and then I can create some PRs if they turn out to be good :

In devcontainer.json, add these settings for better automatically checking for Clang errors. VSCode shows nicely the problems and underlines the problematics line.

"C_Cpp.codeAnalysis.runAutomatically": true,  // For automatically run code analysis on save
"C_Cpp.codeAnalysis.clangTidy.enabled": true, // Clang tidy checks are included when it is run code analysis
"C_Cpp.codeAnalysis.exclude": { // Exclude checking in out directory (using presets). Maybe need some other folders too.
    "${workspaceFolder}/out/**": true

And add extension:
"cheshirekow.cmake-format" // For automatically run formating cmake files on save
This extension must have installed cmake-format. Because of this, we need to add in Dockerfile:
RUN python3 -m pip install cmake_format

In .clang-tidy I always like to add CheckOptions for example:

CheckOptions:
  - { key: readability-identifier-naming.NamespaceCase,          value: lower_case }
  - { key: readability-identifier-naming.ClassCase,              value: CamelCase  }
  - { key: readability-identifier-naming.StructCase,             value: CamelCase  }
  - { key: readability-identifier-naming.TemplateParameterCase,  value: CamelCase  }
  - { key: readability-identifier-naming.FunctionCase,           value: CamelCase  }
  - { key: readability-identifier-naming.VariableCase,           value: lower_case }
  - { key: readability-identifier-naming.PrivateMemberSuffix,    value: _          }
  - { key: readability-identifier-naming.ProtectedMemberSuffix,  value: _          }
  - { key: readability-identifier-naming.MacroDefinitionCase,    value: UPPER_CASE }
  - { key: readability-identifier-naming.EnumConstantCase,         value: CamelCase }
  - { key: readability-identifier-naming.EnumConstantPrefix,       value: k         }
  - { key: readability-identifier-naming.ConstexprVariableCase,    value: CamelCase }
  - { key: readability-identifier-naming.ConstexprVariablePrefix,  value: k         }
  - { key: readability-identifier-naming.GlobalConstantCase,       value: CamelCase }
  - { key: readability-identifier-naming.GlobalConstantPrefix,     value: k         }
  - { key: readability-identifier-naming.MemberConstantCase,       value: CamelCase }
  - { key: readability-identifier-naming.MemberConstantPrefix,     value: k         }
  - { key: readability-identifier-naming.StaticConstantCase,       value: CamelCase }
  - { key: readability-identifier-naming.StaticConstantPrefix,     value: k         }

This force developers to use the same naming conventions. What do you think?

One more suggestion is to support the new ubuntu Jimmy.

Build error: optimization flag '-fno-fat-lto-objects' is not supported

This is output from cmake --build ./build in the Docker container (Ubuntu host machine):

[  0%] Building CXX object _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o
[  0%] Building CXX object _deps/fmt-build/CMakeFiles/fmt.dir/src/os.cc.o
[  0%] Linking CXX static library libfmt.a
[  0%] Built target fmt
[  0%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/spdlog.cpp.o
[  1%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/stdout_sinks.cpp.o
[  1%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/color_sinks.cpp.o
[  1%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/file_sinks.cpp.o
[  1%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/async.cpp.o
[  3%] Building CXX object _deps/spdlog-build/CMakeFiles/spdlog.dir/src/cfg.cpp.o
[  3%] Linking CXX static library libspdlog.a
[  3%] Built target spdlog
[  5%] Building CXX object src/sample_library/CMakeFiles/sample_library.dir/sample_library.cpp.o
error: optimization flag '-fno-fat-lto-objects' is not supported [clang-diagnostic-ignored-optimization-argument,-warnings-as-errors]
7 warnings generated.
Suppressed 6 warnings (6 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
1 warning treated as error
make[2]: *** [src/sample_library/CMakeFiles/sample_library.dir/build.make:76: src/sample_library/CMakeFiles/sample_library.dir/sample_library.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:3662: src/sample_library/CMakeFiles/sample_library.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

The error is optimization flag '-fno-fat-lto-objects' is not supported . From a quick Google search, this post on StackOverflow says that the solution is to include the compiler flag -Wno-ignored-optimization-argument.

I just followed the instructions for building in the Docker container, so I would expect it to work without modification. Is this project not maintained anymore?

Issues with automatic VS environment setup via vcvarsall.bat

I believe there are some issues with the way this template attempts to automatically run vcvarsall.bat when compiling with MSVC on Windows.

First Issue: Trailing slashes in environment variables

The first issue is related to how CMake handles lists. After executing vcvarsall.bat, your cmake script copies the environment to string, makes some replacements, and then copies the environment to the current cmake environment. This works fine until an environment value has a trailing backslash at the end of its value (e.g JAVA_HOME).

When this happens, you end up with a list in CMake that looks something like this:

...;JAVA_HOME=C:\Path\To\Java\;LIB=list__sep__of__sep__lib__sep__paths

Because of the trailing backslash, when cmake iterates through the list, it tries to set the JAVA_HOME environment to C:\Path\To\Java;LIB=list;of;lib;paths. The only way I've found to work around this behavior is to also replace all slashes in the environment output with slash and restore them before setting the environment variable.

Second Issue: The VS Environment is lost after the configure step

Running cmake to configure the project works, since the script sets up the VS environment automatically (assuming you don't lose the LIB environment variable due to the previous issue like I did). The problem is the environment is lost again after the configure step, so trying to build will fail indicating it can't find the necessary compiler/link executable. This occurred while using the Ninja generator. I don't know if this occurs with the MSVC generator.

The only way to fix this is to manually run vcvarsall.bat again before executing the build step. I haven't figured out a way to avoid this problem.

At least that was my experience.

Feedback about the template.

Hello,

I just tried the template. Things are working correctly!

I only had two issues build. It blocked me 10min.

  • I installed conan and got weird errors. They were really not easy to diagnose. The fix was to make python3 the default alternative instead of python2.7.
  • clang-tidy is a "required-dependency". It might worth mentioning it in: README_dependencies.md or making it work without it.

Some comments:

  1. Bitmap::Render writes into the [0, width-1] x [0, height-1] box. However you might get an area smaller than what was asked in ComputeRequirement().
    This would normally result in out of bounds errors.
    Fortunately, FTXUI has the concept of a "stencil", inhibiting writing outside of the box assigned to you:
    https://github.com/ArthurSonzogni/FTXUI/blob/548fa51b7115551b42c0f12235de9eb79e7e33e3/src/ftxui/screen/screen.cpp#L408-L413
    So this works, despite this. Not sure if you knew it.

  2. I see Bitmap::SetBox overrides Node::SetBox, but provide the same implementation has the default one. You might want to remove this line if this wasn't added purposefully to help people to learn it.

  3. spdlog is included, but I don't see any usage. I am not sure how this will interact with FTXUI, if used.

  4. You can replace:

  auto container = ftxui::Container::Horizontal(all_buttons);

  auto renderer = ftxui::Renderer(container, make_layout);

by

auto renderer = Renderer(make_layout);

The Renderer function "decorates" a component, by replacing it's "Render()" function implementation, by the one provided. This is a alternative to using c++ composition/inheritance, that is sometimes quicker to write.
In your case, the decorated component doesn't do much. So the second version taking only the function rendering the interface can be used.

What is the package maintainer ?

Hi,

I am trying to use your template for a project of mine.
Unfortunately, I am not sure I understand the definition of the package maintainer ( myproject_PACKAGING_MAINTAINER_MODE)

I the myproject_PACKAGING_MAINTAINER_MODE considered the build for production and the other is build in development ?

Why is WARNING_AS_ERRORS OFF by default ?
Why is ENAME_SANITIZER_** set within the if<->else ? Could this not just be defined in front of the if ?
Why is myproject_ENABLE_IPO be disabled on Package Maintainer mode ? Would't it make more sende to disable it in NON-PACKAGE_MAINTAINER mode ?

I would be really happy if someone could untangle my confusion a bit :-)

Checking version doesn't work

add_test(NAME cli.version_matches COMMAND intro --version)
set_tests_properties(cli.version_matches PROPERTIES PASS_REGULAR_EXPRESSION "${PROJECT_VERSION}")

Doesn't work as PROJECT_VERSION is version from

project(CmakeConfigPackageTests LANGUAGES CXX)

and not from root project.

We can use CMAKE_PROJECT_VERSION, but this will break tests when our project isn't top one.

But this should work as we return if

# Don't even look at tests if we're not top level
if(NOT PROJECT_IS_TOP_LEVEL)
  return()
endif()

Warnings on constexpr testing

Hi guys,

maybe someone here can help me.

I don't quite understand the idea of the constexpr tests. My compiler (Apple Clang 15.0.0) resolves the static checks at compile time, and then throws warnings like

warning: Condition 'factorial_constexpr(0)==1' is always true [knownConditionTrueFalse]
STATIC_REQUIRE(factorial_constexpr(0) == 1);

/.../.../constexpr_tests.cpp:7:37: note: Calling function 'factorial_constexpr' returns 1
STATIC_REQUIRE(factorial_constexpr(0) == 1);

/.../.../constexpr_tests.cpp:7:41: note: Condition 'factorial_constexpr(0)==1' is always true
 STATIC_REQUIRE(factorial_constexpr(0) == 1);

and then, because warnings are promoted to errors, the build fails.

Is this on purpose? I mean, the idea is to check that this is the behavior and then disable the tests?

Thanks.

Pablo

library_export purpose

Hi, it's more educational question what is the purpose of the library_export.hpp file?

Build fails due to _FORTIFY_SOURCE requires compiling with optimization (-O)

Hi
Thank you for this template. I am a fan. Have all the books :)

I tried to build this as is on Linux Arch.
Configuration was OK but build failed due to a required optimization as mentioned in the error below. I tough this might be helpfull to have a look at it.

Salim

/catch_matchers_quantifiers.cpp:8:
/usr/include/features.h:414:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
  414 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
      |    ^~~~~~~
[114/196] Building CXX object _deps/ftxui-build/CMakeFiles/screen.dir/Debug/src/ftxui/screen/color.cpp.o
FAILED: _deps/ftxui-build/CMakeFiles/screen.dir/Debug/src/ftxui/screen/color.cpp.o 
/usr/bin/c++ -DCMAKE_INTDIR=\"Debug\" -I/home/salim/.cache/CPM/ftxui/56a5c8369b2a8eeef461d171119057c3d5ffb926/src -I/home/salim/.cache/CPM/ftxui/56a5c8369b2a8eeef461d171119057c3d5ffb926/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -fcf-protection -fstack-clash-protection  -D_GLIBCXX_ASSERTIONS -g -std=c++20 -flto=auto -fno-fat-lto-objects -Wall -Werror -Wextra -Wcast-align -Wdeprecated -Wmissing-declarations -Wnon-virtual-dtor -Wnull-dereference -Woverloaded-virtual -Wpedantic -Wshadow -Wunused -MD -MT _deps/ftxui-build/CMakeFiles/screen.dir/Debug/src/ftxui/screen/color.cpp.o -MF _deps/ftxui-build/CMakeFiles/screen.dir/Debug/src/ftxui/screen/color.cpp.o.d -o _deps/ftxui-build/CMakeFiles/screen.dir/Debug/src/ftxui/screen/color.cpp.o -c /home/salim/.cache/CPM/ftxui/56a5c8369b2a8eeef461d171119057c3d5ffb926/src/ftxui/screen/color.cpp
In file included from /usr/include/c++/13.2.1/x86_64-pc-linux-gnu/bits/os_defines.h:39,
                 from /usr/include/c++/13.2.1/x86_64-pc-linux-gnu/bits/c++config.h:679,
                 from /usr/include/c++/13.2.1/cstdint:38,
                 from /home/salim/.cache/CPM/ftxui/56a5c8369b2a8eeef461d171119057c3d5ffb926/include/ftxui/screen/color.hpp:4,

myproject_ENABLE_ADDRESS_SANITIZER should be myproject_ENABLE_SANITIZER_ADDRESS

In this piece of code:

if(myproject_BUILD_FUZZ_TESTS)
  message(AUTHOR_WARNING "Building Fuzz Tests, using fuzzing sanitizer https://www.llvm.org/docs/LibFuzzer.html")
  if (NOT myproject_ENABLE_ADDRESS_SANITIZER AND NOT myproject_ENABLE_THREAD_SANITIZER)
    message(WARNING "You need asan or tsan enabled for meaningful fuzz testing")
  endif()
  add_subdirectory(fuzz_test)

endif()

could it be that myproject_ENABLE_ADDRESS_SANITIZER should be myproject_ENABLE_SANITIZER_ADDRESS and myproject_ENABLE_THREAD_SANITIZERshould be myproject_ENABLE_SANITIZER_THREAD` ?

UNITY_BUILD doesn't seem to propagate to dependent projects

From this line of code:
https://github.com/cpp-best-practices/cmake_template/blob/d19d8921771ba582824948f0cc57f849a5c6efd8/ProjectOptions.cmake#L147C3-L147C98
One can get the impression that linking to myproject_options would be sufficient to enable unity build on a project. As far as I can tell that is not correct, the UNITY_BUILD property seems to not propagate to dependent projects. Or am I missing something here?

If one doesn't want set UNITY_BUILD globally, l guess one have to set the property for each target explicitly...

Project not compiling with gcc-13

It seems later versions of GCC requires the -O to FORTIFY this makes the compilation error fail with:

[115/198] Building CXX object _deps/catch2-build/src/CMakeFiles/Catch2.dir/catch2/matchers/catch_matchers_string.cpp.o
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/matchers/catch_matchers_string.cpp:8:
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/../catch2/matchers/catch_matchers_string.hpp:11:
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/../catch2/matchers/catch_matchers.hpp:11:
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/../catch2/matchers/internal/catch_matchers_impl.hpp:11:
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/../catch2/internal/catch_test_macro_impl.hpp:12:
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/../catch2/internal/catch_assertion_handler.hpp:11:
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/../catch2/catch_assertion_info.hpp:12:
In file included from /home/user/.cache/CPM/catch2/8336fa0dd617945aa607363db497172b01dc4bf1/src/catch2/../catch2/internal/catch_source_line_info.hpp:11:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/cstddef:49:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/x86_64-pc-linux-gnu/bits/c++config.h:679:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.1.1/../../../../include/c++/13.1.1/x86_64-pc-linux-gnu/bits/os_defines.h:39:
/usr/include/features.h:413:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings]
#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
   ^
1 warning generated.

For all sources files, and as -Werror is enabled the whole compilation fails for GCC and CLANG.

I inspected the problematic file /usr/include/features.h:413:4 and here is the content:

#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
# if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
# elif !__GNUC_PREREQ (4, 1)
#  warning _FORTIFY_SOURCE requires GCC 4.1 or later
# elif _FORTIFY_SOURCE > 2 && (__glibc_clang_prereq (9, 0)		      \
			       || __GNUC_PREREQ (12, 0))

#  if _FORTIFY_SOURCE > 3
#   warning _FORTIFY_SOURCE > 3 is treated like 3 on this platform
#  endif
#  define __USE_FORTIFY_LEVEL 3
# elif _FORTIFY_SOURCE > 1
#  if _FORTIFY_SOURCE > 2
#   warning _FORTIFY_SOURCE > 2 is treated like 2 on this platform
#  endif
#  define __USE_FORTIFY_LEVEL 2
# else
#  define __USE_FORTIFY_LEVEL 1
# endif
#endif
#ifndef __USE_FORTIFY_LEVEL
# define __USE_FORTIFY_LEVEL 0
#endif

It seems it only wants to use FORTIFY for __OPTIMIZE__ > 0.


For the meantime, do you recommend disabling FORTIFY or downgrading GCC?

Thanks for your time and this great repository.

EDIT 1:

  • Platform: ArchLinux
  • GCC: 13.1.1 20230429

Build in Visual Studio IDE is broken

Building intro.exe using Visual Studio IDE (17.8.5) is broken due to warnings emitted by clang-tidy and cppcheck. There are also compile errors involving lefticus::tools. Building on the command line using CMake seems to work.

  1. clang-tidy complains about many missing includes (misc-include-cleaner) in main.cpp:
    image
  2. The compiler (both cl and clang-cl) throws an error when attempting to add an int literal to a lefticus::tools::uint_np8_t:
    image
    image
  3. cppcheck issues warnings (treated as errors) when checking the constexpr tests:
    image

There are other build issues as well, such as Debug builds being broken due to the use of address sanitizer with the -MDd compiler option (see #59). I realize that perhaps building was intended to be done from the command line with this template (as mentioned before, command line builds seem to work), but when developing on windows being able to make use of Visual Studio for editing and running/debugging my code is important. This template should be made compatible with Visual Studio IDE builds.

Verify docker scripts

Docker scripts should be tested and verified. I (@lefticus) don't work with docker and don't have the necessary experience to see if the docker scripts make sense.

Add test for fetchcontent

  1. make a new project from this project template
  2. make a different new project from this project template
  3. have the first project include the second project
  4. see if we can build

Using MSVC debug-builds fail due to MDd linkage

Building the MSVC debug targets currently fails due to unsupported mix of debug runtime and 'fsanitize=address' option
error : invalid argument '-MDd' not allowed with '-fsanitize=address' [clang-diagnostic-error]
note: AddressSanitizer doesn't support linking with debug runtime libraries yet
Error while processing E:\develop\projects\ad_astra\src\sample_library\sample_library.cpp.

-Wsign-conversion is redundant

-Wsign-conversion # warn on sign conversions

According to Clang diagnostics (https://clang.llvm.org/docs/DiagnosticsReference.html#wconversion), -Wconversion controls -Wsign-conversion. This is the same as GCC (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wsign-conversion), although this only applies to the ${CLANG_WARNINGS} section.

I haven't tried removing -Wsign-conversion and seeing if it still catches it, but perhaps someone else can to verify this behavior. Per the spec, it should be a redundant flag.

How to install shared library

Hi!

A simple use case, need to install myproject::sample_library from this example as shared lib of course with all needed include files. How to do this? Is there a magic "install function" like myproject_package_project or should I manually write my own cmake install lines?

Verify documentation

The documents should be tested and verified by someone who does not know how to work with this template yet (ie, not @lefticus)

Incorrect README.md statement on the main branch

Hey Jason,

I know you've just done the overhaul according to your youtube video but the main branch README.md still says

NOTE This is undergoing a major overhaul on a new branch currently.

Is this correct or is there another overhaul coming?

Cheers!

ctest run tests from dependencies

ctest -C ${{matrix.build_type}} -j ${{env.nproc}}

In the CI runs every test from all dependencies, I realized that it imports almost a thousand tests from Eigen.

ci workflow run failed in Windows (My compiler and everything is in WSL)

repository

I followed the video instructions and the README_troubleshooting.md steps (the last 2 weren't very helpful since I have never used conan before, I just installed it on my own). The problem persists.

OS: Windows ("naked" environment, no compiler, not a lot of programs or tools here)
¿sub OS?: WSL (here is where I have everything I use)
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal

problematic jobs:

  • all test ubuntu 20.04 gcc-11
  • all test macos-10.15 gcc-11
  • test ubuntu 20.04 gcc-11 Unix makefiles, Debug On
  • Test windows-2022, msvc Visual Studio 17 2022, Debug On
  • Test windows-2022, msvc Visual Studio 17 2022, Release On

previously i have installed conan, this is its path: /usr/local/bin/conan

these are the versions of compilers i have in WSL
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
g++-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

Link Youtube videos as comments in the CmakeList files pls

Hey Jason,

I love watching your videos, pretty much that's my latest hobby now.

But there's a ton of your video across various C++ domains, so its becoming difficult to associate the code to video if someone comes here first, It would be great if you can link some of your videos as comments/links in the CmakeList file so that we can go to that video to watch it and get a better idea of what you have done.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.