Difference between revisions of "CMake Policies Design Discussion"

From KitwarePublic
Jump to navigationJump to search
Line 1: Line 1:
This page describes a proposal for a formal backwards/forwards compatibility feature.
This page describes a proposal for a formal backwards/forwards compatibility feature.
=Motivating Examples=
==add_definitions==


Consider code such as
Consider code such as
Line 28: Line 32:


just to get CMake to do the right thing.  For compatibility CMake would have to implement the wrong behavior by default forever.
just to get CMake to do the right thing.  For compatibility CMake would have to implement the wrong behavior by default forever.
==Link Directories==
blah
=Proposed Solution=


Brainstorming:
Brainstorming:

Revision as of 20:08, 25 February 2008

This page describes a proposal for a formal backwards/forwards compatibility feature.

Motivating Examples

add_definitions

Consider code such as

 add_definitions("-DFOO=\\\"hello\\ world\\\"")

which tries to add the option

 -DFOO=\"hello\ world\"

to the compile command line. The code works in CMake 2.4's Unix Makefiles generator and produces a definition as if

 #define FOO "hello world"

appeared in the source code. It works only because of the way the makefile generator happens to place the definition string in the command line. It may not work with the VS IDE generators. In CMake HEAD we provide the COMPILE_DEFINITIONS directory property so that one may write

 set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS "FOO=\"hello world\"")

to get the correct behavior on all generators. Since CMake HEAD contains the appropriate escaping support it is desirable to allow the user to write

 add_definitions("-DFOO=\"hello world\"")

and get the expected behavior. Unfortunately if we were to start escaping the definitions given to add_definitions we would break compatibility with projects that are already adding their own escapes. In hindsight we should have either supported escapes from the beginning or make the command give an error that the definition value is not supported, but it is too late now. A similar problem appears in the add_custom_command command where support for properly escaping all arguments was added late. The solution currently used by that command is to require the user to add a VERBATIM argument to the command to get proper escaping. Using that solution for add_definitions would make the user write

 add_definitions(VERBATIM "-DFOO=\"hello world\"")

just to get CMake to do the right thing. For compatibility CMake would have to implement the wrong behavior by default forever.

Link Directories

blah

Proposed Solution

Brainstorming:

 cmake_feature(PUSH)
 cmake_feature(SET CM00001 FIXED)
 cmake_feature(VERSION 2.6)
 cmake_feature(POP)
 REQUIRED - Project must declare fixed
 FIXED - New behavior
 QUIET - Old behavior
 WARN - Old behavior, emit warning
 ERROR - No behavior, emit error