[cmake-developers] Backward compatbility code

[Brad King]

On 02/11/2014 07:16 AM, Stephen Kelly wrote:
> Ok, I'm not sure how to handle these two items. I've never used the SOURCE 
> signature of add_custom_command, and the AddCustomCommandOldStyle method 
> seems to also relate to things I haven't used before, so I wouldn't know how 
> to explain the policy.

Oops, please disregard my mention of non-VERBATIM mode for the OldStyle
methods.  I mixed that up with the escapeOldStyle arguments.

The cmMakefile::AddCustomCommandOldStyle method is all about translating
the signatures of add_custom_command that used the SOURCE option to modern
signatures.  The SOURCE option was there because custom commands were
first designed with VS 6 in mind, and the VS IDE project files associate
custom commands with their input source file rather than the output.
Nowadays we use dummy output.rule or the MAIN_DEPENDENCY to attach rules
to a source file in the IDE as an implementation detail and prefer to
think about custom commands as associated with their output.  Therefore
the SOURCE signatures no longer make sense so a policy could remove them.
Comments in cmMakefile::AddCustomCommandOldStyle about the meaning of
the SOURCE signatures are all the information I know on them.

>>>    // For backwards compatibility replace varibles in source names.
>>>  -  // This should eventually be removed.
>>>  +  // TODO: This should eventually be removed.
>>>    this->Makefile->ExpandVariablesInString(src);
>>
>> A policy should be added to remove this behavior.
> 
> Any idea how to unit test this?

The above expansion makes this code work:

 set(sources foo.c)
 add_executable(foo \${sources})

but shouldn't with the policy.

-Brad