[cmake-developers] Ideas on Properties
Brad King
brad.king at kitware.com
Mon Oct 23 13:49:02 EDT 2006
Ken Martin wrote:
> One idea is to make properties member variables and then basically wrap the
> C++ classes into CMake. Effective I'm guessing this boils down to
>
> add_target(fubar foo.c bar.c)
>
> fubar(METHOD ARG ARG ARG)
> foo(METHOD ARG ARG)
>
> or maybe
>
> invoke(fubar METHOD ARG ARG ARG)
> invoke(foo METHOD ARG ARG)
>
> depending on how you like to wrap objects. Then each property could be added
> as a Set/Get method on the C++ object what would get wrapped into CMake. But
> it doesn't fit well with properties that may be added and used by CMake
> scripts at Configure time and i doesn't really fit with the rest of the
> language.
I don't like this. It is too direct and low-level.
> Another idea is to add CMake commands to work with properties. For example
>
> # this records the name of the property, and provides help without setting
> it
> DEFINE_PROPERTY(SCOPE NAME "help string comment" [TYPE] [CHAIN])
>
> where scope is GLOBAL, CACHE, DIRECTORY, TARGET, FILE
>
> chain indicates if the property is not found in the current scope if it
> should then check the broader scopes in order File, target, directory, cmake
>
> # retrieve the value of a property
> GET_PROPERTY(VAR SCOPE PROPNAME)
>
> SCOPE would be GLOBAL, CACHE, DIRECTORY dirname, TARGET tgtname, SOURCE
> srcname
>
> # and set values
> SET_PROPERTIES(SCOPE [SCOPE 2] ... [SCOPE N]
> PROPERTIES NAME1 VALUE1 NAME2 VALUE2 ...)
>
> Then CMake can be run to produce help for all the properties that have been
> defined (using DEFINE_PROPERTY) which provides a mechanism for
> documentation. On the down side it is effectively gluing on a bit of OO onto
> a language that is clearly not OO. Also it overlaps a tad with the notion of
> a variable so there could be some confusion between properties and
> variables. We also have a bunch of SET_TARGET_PROPERTIES type commands
Can you give examples of how some current global vars would be
implemented in this framework?
On the other hand all these settings are things that are tested by C++
code at generate time and generally ignored by CMakeLists.txt code
(other than setting). If we formalized some of the Property map ivars
in cmSourceFile, cmTarget, etc. to map some properties directly to other
ivars then setting/getting would not need a change to the CMake
language. As part of the formalization we would add documentation
strings to all such properties in the C++ code.
-Brad
More information about the cmake-developers
mailing list