define_property(): Requiring a prefix for INITIALIZE_FROM_VARIABLE may be counter-productive
In putting together an example for the new INITIALIZE_FROM_VARIABLE
feature added to define_property()
for CMake 3.23, I've encountered an unintended side-effect of the current constraints imposed on the variable name. Currently, we require that the variable name ends with the property name (which I still agree with), but we also require a non-empty prefix for the variable name. The original thinking, as discussed in #20698 (comment 1052002), was to discourage projects from using overly generic property names, but we appear to have ended up implementing the constraint on the variable name instead.
The down side of the current constraint is that it actually drives projects to not make the property names sufficiently unique. Ideally, we'd like property names of the form <PROJNAME>_BLAH
, but since we require variables to have a non-empty prefix, that would mean adding another project-specific prefix on top of the already project-specific property name. Repeating the prefix (i.e. <PROJNAME>_<PROJNAME>_BLAH
) looks both strange and seems like unnecessary duplication. More likely, projects will drop the prefix from the property and instead use BLAH
for the property name and <PROJNAME>_BLAH
for the variable name. This fails our goal of trying to encourage unique property names.
I propose that we drop the constraint that variable names must have a non-empty prefix (but they should still end with the property name). Instead, we should put a constraint on the property name when INITIALIZE_FROM_VARIABLE
is used. That property name must contain at least one underscore. This still gives projects wiggle room if they really don't want to add a project-specific prefix and insist on generic names like NO_UNICODE_DEFINES
(which would be relevant for Qt properties, for example).
It might also be worthwhile adding an example to the define_property()
docs showing some appropriate patterns (once !7090 (merged) has been merged).