At this point, it is an interface to the cache. It will be extended
to be a universal interface for access to and manipulation of
configuration-time data (defintions, properties on targets,
directories, source files etc).
This will allow porting all command implementations away
from the cmMakefile and cmTarget classes, and result in something
more-purely related to configuration-time processing of cmake
commands. That should serve at least the following goals:
* Split the CMake implementation more definitively into three
stages: Configuration, computation and generation, and be able to
implement each optimally for memory access patterns etc.
* Make better IDE integration possible by making more configuration
data available.
* Make it possiblte to use a smaller library than CMakeLib.a in
cpack and ctest, resulting in smaller executables.
* Make it possible to run the configure step multiple times in
the same CMake run (#14539).
Manage its lifetime in the cmake class, and add a convenience accessor
to cmMakefile.
This is for consistency with other CMake access interfaces such as
definitions and properties which use a null value as a 'not present'
value. It is source compatible with existing callers, and it returns
a pointer into actual real cache entry storage.
This topic was never tested without some follow-up commits. The
GetCacheEntryValue API returns a pointer to memory freed on return.
It will have to be revised along with the rest of the original topic.
9410e24a cmCacheManager: Port consumers to non-iterator API.
7b7ae3b1 Port QtDialog to non-iterator cache API.
228c629c Port CursesDialog to non-iterator cache API.
2e50f5e7 cmMakefile: Port away from CacheEntry.Initialized.
e6224367 cmCacheManager: Add non-iterator-based API.
9ada4c04 cmCacheManager: Rename GetCacheValue to GetInitializedCacheValue.
1fe7f24c Add API for cache loading, deleting and saving to the cmake class.
08c642c6 cmMakefile: Remove cache version accessors.
cec8f97e cmMakefile: Simplify GetDefinitions implementation.
VS 2013 originally claimed to support initializer lists but a bug was
found in which it generated bad code silently. For this reason we
previously considered support to not be present. However, Update 3 adds
a hard error on cases that previously generated bad code, so it is now
safe to use initializer lists with VS 2013 Update 3 or greater. At
worst a compiler error will be issued in the cases that do not work, but
that is no different from any other compiler-specific workaround a
project code may need.
The only reason this failed to compile on VS 2013 was because the
compiler uses different initializer_list constructor argument types than
our dummy implementation. The standard does not specify the non-default
constructor argument types for initializer_list. Use a template to
match any two-arg constructor a compiler might select (e.g. begin/end or
begin/len). Use #error to preserve the error on VS 2013.
c37cf7fa cmCacheManager: Remove unused method
64556e3d cmCacheManager: Remove unused overloads.
23bb5d22 cmCacheManager: Remove use of intermediate overload.
510562e3 cmGlobalGenerator: Don't fetch the cache manager in a loop.
629e9489 cmake: Clear member rather than explicit erase.
d280bae9 cmake: Be clear that there is no chaining after global properties.
364c7ea1 cmake: Remove unused method.
47acfe1d cmake: Remove unused member.
a469bf7b cmMakefile: Remove one wrong and one insufficiently helpful comment.
257c1649 cmListFile: Remove unused member.
fe17092c cmMakefile: Remove bogus comment.
199b28ac Remove duplicate tag name.
6f82b5e8 Help: Link to properties in set_tests_properties.
66f5af29 Help: Link to properties in set_directory_properties docs.
f7dd3f7c Help: Add link in set_source_files_properties command docs.
3b256173 Help: Shorten too-long title marker.
8fc3a2fb Help: Add references to cmake-property sections.
RPM, DEB and archive packages were not created
in cases when CPACK_<generator>_COMPONENT_INSTALL
was set to ON and a single component existed.
Patch also changes CPackRPM test to implicitly
test for this case.