You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One side effect of the TriBITS refactoring that generates <tplName>Config.cmake files with modern IMPORTED targets of the name <tplName>::<libname> is that then can conflict with imported targets of the same name generated by other package config files and find modules. For example, imported targets like CUDA::cufft generated by the refactored FindTPLCUDA.cmake module conflict with IMPORTED targets of the same name generated by the newer FindCUDAToolkit.cmake file module (see trilinos/Trilinos#10954 (comment) which was addressed with PR #528.) Another example is the SEACAS TriBITS TPL find module FindTPLfmt.cmake which generates the IMPORTED target fmt::fmt which conflicts with the IMPORTED target fmt::fmt generated by the Findfmt.cmake find module (see trilinos/Trilinos#11284).
Discussion
Initially, my thoughts were that we should be upgrading the TriBITS TPL find modules FindTPL<tplName>.cmake to call find_package(<tplName>) (which is what was done in PR #528). Then it was suggested in trilinos/Trilinos/11284 to prefix all of the TriBITS-generated targets with TPL:: which is what was done in microsoft/vcpkg/27928. However, doing that for even the <tplName>::all_libs target breaks the proposed standard for CMake packages.
Proposed solution
The proposed solution is change the target names of just the intermediate targets like <tplName>::<libname> where we have seen conflicts as described by namespacing them with tribits:: to produce tribits::<tplName>::<libname>. Now, the INTERFACE target <tplName>::all_libs would not be renamed so it would not break any of the code that looks for that name or break the proposed standard. Note that this does not restrict the usage of the TriBITS-produced targets in any way because they were not usable on their own because they don't have the include directories needed to use them. The include directories are only added to the <tplName>:all_libs target.
The text was updated successfully, but these errors were encountered:
…riBITSPub#299)
This is to avoid clashes such as reported in:
* TriBITSPub#548
like CUDA::cufft from FindCUDAToolkit.cmake and fmt::fmt from Findfmd.cmake.
With the merge of PR #549, this should be addressed from the TriBITS perspective. We just need to update the snapshot to Trilinos 'develop' and this will be resolved in Trilinos as well.
Description
One side effect of the TriBITS refactoring that generates
<tplName>Config.cmake
files with modern IMPORTED targets of the name<tplName>::<libname>
is that then can conflict with imported targets of the same name generated by other package config files and find modules. For example, imported targets likeCUDA::cufft
generated by the refactoredFindTPLCUDA.cmake
module conflict with IMPORTED targets of the same name generated by the newerFindCUDAToolkit.cmake
file module (see trilinos/Trilinos#10954 (comment) which was addressed with PR #528.) Another example is the SEACAS TriBITS TPL find moduleFindTPLfmt.cmake
which generates the IMPORTED targetfmt::fmt
which conflicts with the IMPORTED targetfmt::fmt
generated by theFindfmt.cmake
find module (see trilinos/Trilinos#11284).Discussion
Initially, my thoughts were that we should be upgrading the TriBITS TPL find modules
FindTPL<tplName>.cmake
to callfind_package(<tplName>)
(which is what was done in PR #528). Then it was suggested in trilinos/Trilinos/11284 to prefix all of the TriBITS-generated targets withTPL::
which is what was done in microsoft/vcpkg/27928. However, doing that for even the<tplName>::all_libs
target breaks the proposed standard for CMake packages.Proposed solution
The proposed solution is change the target names of just the intermediate targets like
<tplName>::<libname>
where we have seen conflicts as described by namespacing them withtribits::
to producetribits::<tplName>::<libname>
. Now, the INTERFACE target<tplName>::all_libs
would not be renamed so it would not break any of the code that looks for that name or break the proposed standard. Note that this does not restrict the usage of the TriBITS-produced targets in any way because they were not usable on their own because they don't have the include directories needed to use them. The include directories are only added to the<tplName>:all_libs
target.The text was updated successfully, but these errors were encountered: