Add SFML:: namespace to targets

[ChrisThrasher]

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:

1. It's more idiomatic. Modern CMake libraries are expected to
   have namespaced targets.

2. 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

• Tested on Linux
• Tested on Windows
• Tested on macOS
• Tested on iOS
• Tested on Android

How to test this PR?

Build and install SFML. Find and use the package in the following way:

find_package(SFML 3.0.0 REQUIRED COMPONENTS graphics)
...
target_link_libraries(some-target PRIVATE SFML::graphics)

[Bromeon]

Should we not use this chance and make module names consistent everywhere, i.e. PascalCase?

We have #include <SFML/Graphics.hpp>, so SFML::Graphics would be standing to reason in my opinion.

[ChrisThrasher]

That's fine by me. I'll make the change as soon as the team comes to a consensus.

[ChrisThrasher]

If we move to a SFML::Graphics style do we still want to keep the internal target names like sfml-graphics? That can be done but will require some find-replace string operation in sfml_add_library to automatically capitalize the first letter. sfml-Graphics is a bit unsightly so figuring out that string manipulation is probably worth it.

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.

[Bromeon]

If the user-facing names are consistent (i.e. Graphics), that's already a good start.

What came to my mind now, are the output libraries/binaries, which are probably still sfml-graphics.{dll|so}. I guess that could stay; other namings like SFML-Graphics or SFML_Graphics are rather weird for those.

[ChrisThrasher]

I think I figured out a good way to keep the existing sfml-graphics style targets while adding SFML::Graphics style targets for export and use by downstream targets. I feel good about this implementation.

[ChrisThrasher]

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)

[eXpl0it3r]

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. 😄

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)

Does that mean the lower-case variant will no longer be working?

[ChrisThrasher]

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 graphics and Graphics to be mutually exclusive. Currently it looks like this when users want to depend on SFML

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.