Improved readme

[alexios-angel]

I added compiler explorer links as well as some better examples.

[friendlyanon]

The added CMake example has issues on almost every single line.

[friendlyanon]

ToC is already provided by GitHub's UI.

[alexios-angel]

I am using the github.com website that's why I created the ToC

[friendlyanon]

Yes, GitHub UI provides a ToC already:

[alexios-angel]

Oh I didn't know that

[friendlyanon]

CMake 3.8 does not know about C++20, you must not use this value. Please read the docs:

New in version 3.12

This is not the way to set the standard requirement of a target, you must use compile features for that.

[alexios-angel]

Oh,

For compilers that have no notion of a standard level, such as Microsoft Visual C++ before 2015 Update 3, this has no effect.

[friendlyanon]

The include is missing and please read the docs:

New in version 3.11

[alexios-angel]

Oh I totally forgot that
include(FetchContent)

[alexios-angel]

Suggested change

	FetchContent_Declare(
	ctre
	GIT_REPOSITORY https://github.com/hanickadot/compile-time-regular-expressions.git
	GIT_TAG 95c63867bf0f6497825ef6cf44a7d0791bd25883 # v3.4.1
	)

[friendlyanon]

Please read the docs:

New in version 3.14

If #230 is merged then this becomes entirely wrong, as using ctre would simply be:

find_package(ctre REQUIRED)
target_link_libraries(project_target PRIVATE ctre::ctre)

[alexios-angel]

I think that if the package was not found we could do

(pseudocode)

find_package(ctre)
if(package not found){
    FetchContent(ctre)
    include_target_directories(ctre dir)
}

[friendlyanon]

That's not the responsibility of this project. There are many ways to "polyfill" a find_package call. It should instead just use idiomatic CMake in examples.

[alexios-angel]

I guess

Suggested change

	FetchContent_MakeAvailable(ctre)
	find_package(ctre REQUIRED)
	target_link_libraries(project_target PRIVATE ctre::ctre)

[friendlyanon]

Don't use directory scope commands. Prefer target_include_directories.

[friendlyanon]

Suggested change

	add_executable(${PROJECT_NAME} main.cpp)
	target_link_libraries(${PROJECT_NAME})
	add_executable(example main.cpp)
	target_link_libraries(example PRIVATE ctre::ctre)

[alexios-angel]

I feel that the CMake example would be more of a template if we did

Suggested change

	add_executable(${PROJECT_NAME} main.cpp)
	target_link_libraries(${PROJECT_NAME})
	add_executable(${PROJECT_NAME} main.cpp)
	target_link_libraries(${PROJECT_NAME} PRIVATE ctre::ctre)

[friendlyanon]

Using ${PROJECT_NAME} is pointless either way.

[alexios-angel]

${PROJECT_NAME} makes it so there are fewer things to rewrite.

[friendlyanon]

Find and replace exists. How often does the project name change that this abstraction needs to exist? This also just obfuscates the target's name. There are only downsides to using this.

[alexios-angel]

The project name changes every time someone copies the CMake example template and puts it in their own project. I would say that anyone wanting to not use the variable ${PROJECT_NAME} is already further along in their project where they would only need to Ctrl+C the middle portion of the template.

[friendlyanon]

If this is just for a copy-paste example, then using an explicit name makes no semantic difference, but syntactically aligns better with what one should write to begin with. Anyone sufficiently knowledgeable regarding CMake will not bother with this example, as the only interesting thing is the exported target(s) in the install interface.

[friendlyanon]

with the above sources

What sources?

[alexios-angel]

Ctre

[friendlyanon]

ctre is a header only library, it has no source files and to the headers to the include path you use target_link_libraries(project_target PRIVATE ctre::ctre) (once the appropriate PR is merged).