Skip to content

Conversation

@ClausKlein
Copy link
Contributor

@ClausKlein ClausKlein commented Nov 25, 2024

Use FILE_SET HEADERS for simplify installation.

Use VERIFY_INTERFACE_HEADER_SETS

Prevent use of include(CTest).

Prepare CPack to easy distribution.

NOTE: This is first of a series of PR based on #14

This fix #35

CMakeLists.txt Outdated
Comment on lines 62 to 63
"$<$<COMPILE_FEATURES:cxx_std_23>:cxx_std_23>"
"$<$<NOT:$<COMPILE_FEATURES:cxx_std_23>>:cxx_std_20>"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove these flags. For right now, I believe the Beman standard is to control the C++ standard version via CMAKE_CXX_STANDARD

Copy link
Contributor Author

@ClausKlein ClausKlein Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CMAKE_CXX_STANDARD set it for build time, and it is not set.
But this exports your min required cxx_std on this machine.

see #35

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

inplace_vector targets a min standard of C++17 I believe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note from CI workflow: Needs C++ 20 as C++17 selectively disables ranges and concepts related functionalities!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CK is right here regarding the C++ version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am waiting for a pragmatic decision ...

I will mention this at the meeting tomorrow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mentioned... waiting for someone to come in and review....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been discussed at length elsewhere. We're going with the rule that depending on a Beman target should not change the compiler flags of the dependent. Doing so makes it impossible to build a large project with consistent flags.

If this library requires certain compiler + flag combinations, it should run a feature check at CMake time like what was done with iterator_interface and error out with a good message if there isn't a reasonable workaround.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see my example #33 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@DeveloperPaul123 DeveloperPaul123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just minor comments to address.

@ClausKlein
Copy link
Contributor Author

@wusatosi This PR was requested from you. Any notes?

@wusatosi
Copy link
Member

@wusatosi This PR was requested from you. Any notes?

Thanks! You made this a lot easier to review :P

Thank you for taking my feedback. I am not familiar with this part of CMake

I will leave the review up to @DeveloperPaul123 .

Copy link
Member

@wusatosi wusatosi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confirm this PR fixes the install command and enables all_verify_interface_header_sets.

Nice job @ClausKlein , I will leave the details to @DeveloperPaul123 .

@ClausKlein ClausKlein force-pushed the feature/modernize-cmake branch 4 times, most recently from ecd405a to b6eefec Compare November 27, 2024 06:27
@ClausKlein ClausKlein requested a review from wusatosi November 27, 2024 06:33
@ClausKlein ClausKlein force-pushed the feature/modernize-cmake branch from b6eefec to d06a5dc Compare November 27, 2024 20:10
CMakeLists.txt Outdated
# cmake-format: on

cmake_minimum_required(VERSION 3.23)
set(CMAKE_SKIP_TEST_ALL_DEPENDENCY FALSE)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why wouldn't we want the default here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this setting, it is possible to do make test without make all before.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to see how my suggestion to change the default in CMake plays out. If they're okay with changing the default, I'd be okay with leaving this line in as a temporary solution.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The discussion there has lead me the conclusion that it is not a good practice to use set(CMAKE_SKIP_TEST_ALL_DEPENDENCY FALSE). See this comment for a rationale summary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is your interpretation, not a fact!

cmake_minimum_required(VERSION 3.23)
set(CMAKE_SKIP_TEST_ALL_DEPENDENCY FALSE)

cmake_minimum_required(VERSION 3.25...3.31)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why a range? Why this particular range?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To prevent policy warnings if you use a newer CMake version than v.3.25

I would use 3.30...3.31 today.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There aren't any policies that impact the CMake code in this repository so this isn't needed IIUC.

My preference is to keep the simple cmake_minimum_required(VERSION 3.23) and switch to the ... only in the case that we have a particular CMake policy warning we need to suppress, which hopefully is rare.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not possible!

Comment on lines +18 to +20
if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
message(FATAL_ERROR "In-source builds are not allowed!")
endif()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this check is worth the additional complexity. If people follow our build instructions (e.g. using presets), they should be fine. If this is a big stumbling block, then perhaps this kind of warning should be up-streamed to the Kitware people.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is not desired across beman, we should close bemanproject/exemplar#67 .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is an open issue at CMake to deny in-source builds.

if you do cmake . -L in source_dir instead in binary_dir, please note the generated files in source tree!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ClausKlein please stop falsely marking conversations as resolved.

${PROJECT_IS_TOP_LEVEL}
)

set(CPACK_GENERATOR TGZ)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why set this? Shouldn't the CMake invoker have the decision of what CPack generator to use?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is no restriction, he user has still the choice to use cpack -G ZIP ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a benefit of changing the default here, but I see a cost in complexity.

add_library(beman::inplace_vector ALIAS beman.inplace_vector)

target_include_directories(
target_sources(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code would be better placed in src/beman/inplace_vector/CMakeLists.txt for consistency with beman.exemplar.

Copy link
Contributor Author

@ClausKlein ClausKlein Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not possible, the BASE_DIR is the current directory!

target_sources(
    beman.inplace_vector
    PUBLIC
        FILE_SET inplace_vector_public_headers
        TYPE HEADERS
        BASE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/include
        FILES
            "${CMAKE_CURRENT_SOURCE_DIR}/include/beman/inplace_vector/inplace_vector.hpp"
)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that. See what is done in exemplar.

CMakeLists.txt Outdated
Comment on lines 62 to 63
"$<$<COMPILE_FEATURES:cxx_std_23>:cxx_std_23>"
"$<$<NOT:$<COMPILE_FEATURES:cxx_std_23>>:cxx_std_20>"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been discussed at length elsewhere. We're going with the rule that depending on a Beman target should not change the compiler flags of the dependent. Doing so makes it impossible to build a large project with consistent flags.

If this library requires certain compiler + flag combinations, it should run a feature check at CMake time like what was done with iterator_interface and error out with a good message if there isn't a reasonable workaround.

Comment on lines +4 to +5
CMakeCache.txt
CMakeFiles/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why these files?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Garbage generated be in-source build which cmake .

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should add to our .gitignore to cover cases where users do unsupported things.

Every line of code we add has an associated maintenance cost and an overhead for readers. I don't think, in this instance, the cost justifies the benefit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still unconvinced adding these lines is worth the complexity.

ClausKlein and others added 3 commits December 6, 2024 07:56
Use FILE_SET HEADERS for simplify installation

Set VERIFY_INTERFACE_HEADER_SETS property

Prevent use of include(CTest)

Prepare CPack to easy distribution

Add all_verify_interface_header_sets to CI builds

Prevent in-source builds

Ignore cmake configure trash
Co-authored-by: David Sankel <[email protected]>
@ClausKlein
Copy link
Contributor Author

This is a never ending strory, I Think, you will make it you way.

@ClausKlein ClausKlein closed this Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

build errors on macOS with Apple clang version 16.0.0

4 participants