-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SFML:: namespace to targets #1947
Conversation
Should we not use this chance and make module names consistent everywhere, i.e. We have |
That's fine by me. I'll make the change as soon as the team comes to a consensus. |
If we move to a We also should tweak things such that the following is how clients find SFML package components find_package(SFML 3.0.0 REQUIRED COMPONENTS Graphics) with a capital "G" to further keep things consistent. |
If the user-facing names are consistent (i.e. What came to my mind now, are the output libraries/binaries, which are probably still |
a7f98c6
to
4736f03
Compare
I think I figured out a good way to keep the existing |
3ff0f33
to
9caf8bc
Compare
I updated the component names so instead of writing find_package(SFML 3.0.0 REQUIRED COMPONENTS graphics audio) you write find_package(SFML 3.0.0 REQUIRED COMPONENTS Graphics Audio) |
9caf8bc
to
3816868
Compare
3816868
to
f777c09
Compare
As a German-speaking person I've noticed a major bias towards capitalizing things, so things like that make it hard for me to judge what's better. 😄
Does that mean the lower-case variant will no longer be working? |
That’s right. I believe it’s theoretically possible to support both upper and lower case component names but that would be difficult to implement, especially if you wanted find_package(SFML 3.0.0 REQUIRED COMPONENTS Graphics)
…
target_link_libraries(app PRIVATE SFML::Graphics) #include <SFML/Graphics.hpp> While I don’t feel strong about what is or isn’t capitalized, it does look nice that everything follows this “SFML” + “Graphics” pattern in all places. |
ac21c8d
to
33e556c
Compare
This removes the sfml- prefixed targets from the export set. The sfml- prefixed targets are still available within the build tree but not to downstream users thus making this an API breaking change when compared to the 2.x releases. To keep things consistent, usage of the sfml- targets were replaced with their namespaced counterparts. This has a number of benefits: 1. It's more idiomatic. Modern CMake libraries are expected to have namespaced targets. 2. Namespaced targets are less likely to collide with user-defined targets. No one will accidentally define a SFML:: target. 3. If a namespaced target is not found by CMake, configuration will immediately stop.
33e556c
to
a389c38
Compare
Description
This removes the sfml- prefixed targets from the export set. The sfml- prefixed targets are still available within the build tree but not to downstream users thus making this an API breaking change when compared to the 2.x releases. To keep things consistent, usage of the sfml- targets were replaced with their namespaced counterparts.
This has a number of benefits:
It's more idiomatic. Modern CMake libraries are expected to
have namespaced targets.
Namespaces targets are less likely to collide with user-defined
targets. No one will accidentally define a SFML:: target.
This PR is related to the issue #1562
Tasks
How to test this PR?
Build and install SFML. Find and use the package in the following way: