Maybe we could combine them together: the configuration process would be separated into two stages:
1. Script stage: Look for and run build script, that will generate a [JSON] configuration file. 2. Look for a configuration file, and generate build files according to it. Then, a programmer should decide if he need to use the script stage. If not, he would be able to edit it all with its favorite IDE. If he need the script stage, he would not be able to edit it with a automatic tools. I think we should make the configuration files as simple as we can (`cbp` files are not a good example for a simple file): usable defaults for fields, etc. Adding named condition \ variables would serve only a part of developers needs (for example, choosing source files according to the current OS) but it would prevent developers from being able to customize their building with functions (For example, applying a long set of configurations for each build target to be used as a plugin for an application with a lot of restrictions). On Fri, Jan 13, 2017 at 9:28 PM, Brad King <brad.k...@kitware.com> wrote: > On 01/13/2017 11:45 AM, Shmuel H, wrote: > > * From the other side, programmers should be able to use a script > > language to customize their build process. > > > > For example, a simple declaration (pseudo code): > > cmake_libraries += { > > ["name": "myLib", > > "files": "myLib.c", > > "link_type": "static"] > > } > > The declarative part needs to be self-standing so that it can be loaded > by an IDE, edited by the user, and saved back out in the original format > with a minimal diff. An IDE will have no idea how to write snippets back > into a procedural script. This is one reason CMakeLists.txt files cannot > be edited through an IDE except as text files. > > My proposal is that the declarative part would have most of the build, > but with some kind of named condition/config variables. Then the > procedural part will introspect the system to determine the values of > the configuration variables so that CMake can evaluate the conditions. > > -Brad > > -- > > 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 >
-- 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