[cmake-developers] Developer tasks - Refactoring

[Stephen Kelly]

In order to make it possible to implement fully featured user tools like the 
cmake daemon

 https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/

... and to make it possible to use multiple toolchains at once

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7272

... and turn CMake into a fully capable modern cross-compiling buildsystem

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10873

... the implementation of CMake needs to improve. At least if any of those 
advanced features are to be maintainable.

A large amount of the steps to get there involve refactoring the existing 
CMake code to be more flexible. I have been doing that since April last 
year, but I want to open up the task list to other collaborators and 
newcomers in particular.

Here are some entry-level refactoring tasks which have a useful impact on 
CMake, and which lead to more familiarity with the code for whoever does 
them. Feel free to ask for further guidance on any task.

1) Make cmLocalGenerator not inherit cmOutputConverter
* Change enums like cmLocalGenerator::START_OUTPUT with sed.  See

   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eac15298

  for a similar sed command to achieve this.

* Remove inheritance. Implement Convert() methods in cmLocalGenerator for 
  source compatibility which instantiate and use a cmOutputConverter as in

   https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d8b79ad

2) Reduce generate-time use of cmMakefile definitions
* The intention is to remove direct use of cmMakefile from generate-time 
  code.
* Use an IDE to find uses of cmGeneratorTarget::Makefile and 
  cmGeneratorTarget::Target
* Replace use of 'low-level' GetDefinition from cmMakefile with more 
  'high-level' methods on cmGeneratorTarget.  Eg

   this->Target->Target->GetMakefile()->GetDefinition("CMAKE_STRIP")

  in cmComputeLinkInformation could be replaced with a new

   std::string cmGeneratorTarget::GetCMakeStripTool() const;

  or similar.

3) Compute cmGeneratorTarget state non-lazily in its constructor.
* Historically target state for generators was computed lazily because it 
  might need to be cleared and re-computed.  That is no-longer true.
* For example, the LinkInformation is populated lazily in
  cmGeneratorTarget::GetLinkInformation.
* Instead the LinkInformation could be populated in the cmGeneratorTarget 
  constructor for all known configurations.  That is what generators will 
  request during generate-time anyway.
* Doing this will make it possible to split a cmComputedTarget out of 
  cmGeneratorTarget.

Thanks,

Steve.