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. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers