Introduce cmState class.

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.

1 files changed, 4 insertions, 0 deletions

diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 64b332c..c419edc 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -21,6 +21,7 @@
 #include "cmTest.h"
 #include "cmDocumentationFormatter.h"
 #include "cmAlgorithms.h"
+#include "cmState.h"
 
 #if defined(CMAKE_BUILD_WITH_CMAKE)
 # include "cmGraphVizWriter.h"
@@ -133,6 +134,8 @@ cmake::cmake()
   this->FileComparison = new cmFileTimeComparison;
 
   this->Policies = new cmPolicies();
+  this->State = new cmState(this);
+
   this->InitializeProperties();
 
 #ifdef __APPLE__
@@ -171,6 +174,7 @@ cmake::~cmake()
 {
   delete this->CacheManager;
   delete this->Policies;
+  delete this->State;
   if (this->GlobalGenerator)
     {
     delete this->GlobalGenerator;