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
It is sometimes desired to change the namespace used for the targets created by the various CMake generators so they can match the targets created by naming schemes outside of Conan (such as the built in find modules or system installed packages).
One way to tackle this problem would be to use the filename attribute to control the name given to the fine module, and then change the names attribute to be whatever the namespace needs to be.
However to emulate related packages which may share a namespace for targets generated amongst themselves it becomes necessary to share the value for cppinfo.names attribute between packages. Because that value is then no longer unique, it's necessary to use the filename attribtue to represent a "more unique" value which can be used for generated variables (see the implementation of this PR where the global variables had to incorporate the filename to work with this recreate which contains multiple packages that share a namespace).
It could simplify things to introduce a seperate attribute explicitly tied to the concept of a namespace in generated entities. This could then be used by the cmake generators.
As an example of how this attribute might be used, consider two packages from a theoretical modularized Boost:
the only thing missing IMO to achieve full integration is #7254, so I'd rather have that first and then evaluate if a namespace attribute is really needed in case it makes things easier 😄
It is sometimes desired to change the namespace used for the targets created by the various CMake generators so they can match the targets created by naming schemes outside of Conan (such as the built in find modules or system installed packages).
One way to tackle this problem would be to use the filename attribute to control the name given to the fine module, and then change the
names
attribute to be whatever the namespace needs to be.However to emulate related packages which may share a namespace for targets generated amongst themselves it becomes necessary to share the value for
cppinfo.names
attribute between packages. Because that value is then no longer unique, it's necessary to use thefilename
attribtue to represent a "more unique" value which can be used for generated variables (see the implementation of this PR where the global variables had to incorporate the filename to work with this recreate which contains multiple packages that share a namespace).It could simplify things to introduce a seperate attribute explicitly tied to the concept of a namespace in generated entities. This could then be used by the cmake generators.
As an example of how this attribute might be used, consider two packages from a theoretical modularized Boost:
The text was updated successfully, but these errors were encountered: