The configuration keyword "tags" is reserved to assert a list of labels that should be honored in some suitable way by the features and tasks building the packages. In particular the main use for such tags is to build for debug or optimized binaries for which the tags "debug" and "opt" are reserved.
So far implementing any interpretation of these tags has gone largely ignored.
In general these tags must be interpreted differently by different package features and by the same features operating on different packages. This means the information needed to interpret them must be in the configuration file.
One possibility is to have configuration keys like:
The interpretation of the appended _<tag> is left up to each feature that consumes the configuration items. In the cmake example, if both tags are asserted then the _debug_opt version is used.
The notion of "tags" is really a cop-out to allow re-use of otherwise similar configuration file stanzas. Instead one could use either the configuration hierarchy feature, separate groups or separate configuration files to make the kind of distinctions that "tags" might offer.
The configuration keyword "tags" is reserved to assert a list of labels that should be honored in some suitable way by the features and tasks building the packages. In particular the main use for such tags is to build for debug or optimized binaries for which the tags "debug" and "opt" are reserved.
So far implementing any interpretation of these tags has gone largely ignored.
In general these tags must be interpreted differently by different package features and by the same features operating on different packages. This means the information needed to interpret them must be in the configuration file.
One possibility is to have configuration keys like:
The interpretation of the appended
_<tag>is left up to each feature that consumes the configuration items. In the cmake example, if both tags are asserted then the_debug_optversion is used.The notion of "tags" is really a cop-out to allow re-use of otherwise similar configuration file stanzas. Instead one could use either the configuration hierarchy feature, separate groups or separate configuration files to make the kind of distinctions that "tags" might offer.