Deprecate exported cmake `CGAL` target?

[Andrej730]

Hi! I've stumbled upon an issue - I needed to define a macro in cmake library if it's using CGAL, see the snippet below.

find_package(CGAL CONFIG REQUIRED)
target_compile_definitions(CGAL::CGAL INTERFACE ENABLE_CGAL_SUPPORT)

Which results in an error target_compile_definitions can not be used on an ALIAS target.
Since libraries typically export namespace::target, I was assuming this name would work for this. But investigating cgalconfig.cmake I've learned that it's actually an alias to CGAL target created in a global namespace.

Since I would like to support both official cgalconfig.cmake and also the configs coming from conan and conan is using CGAL::CGAL as the main target (see https://conan.io/center/recipes/cgal), then I need to use some kind of strategy to support both. Currently I'm thinking to create another CGAL::CGAL_INTERFACE target and link CGAL::CGAL to it, as a workaround.

Maybe it's worth considering deprecating CGAL exported target as some point?
As it's the best practice to export targets only to it's own namespace and then there's no need for aliases.

[IAmUKJ]

Proposed Solution

Hi, @Andrej730
After looking into the CGAL CMake configuration, the issue seems to stem from CGAL::CGAL being exported as an ALIAS target to the global CGAL target. Since CMake does not allow modifying properties on alias targets, consumers cannot safely add compile definitions, even though CGAL::CGAL is exposed as the primary namespaced target.

To address this while preserving compatibility, I propose defining CGAL::CGAL as a real INTERFACE target and linking it to the existing CGAL target. Public usage requirements (e.g. compile definitions) can then be attached to CGAL::CGAL, allowing downstream projects—including Conan-based setups—to extend CGAL cleanly. Existing users of the global CGAL target would remain unaffected.

If this approach is acceptable, I’d be happy to implement and validate it across both official and package-manager CGAL configurations.