Hi Daniel, It is not about a specific problem with the CMake language, I have little problems with almost every language (e.g. Python with its variable scopes and destructors, C++ with a few strange standard decisions), nothing is perfect.
However, I think that reinventing the wheel is very bad, especially when there was no intention to create a wheel. The current CMake language is a mix between a config file format and a programming language. Therefore, it has a very strange and not intuitive syntax, as well as challenging scope and variables management. These are not "problems with a language", problems can be fixed, in this case, fixing them would result a completely different language. Regards, Shmuel. On Thu, Jan 12, 2017 at 12:16 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote: > On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, <shmuelhcm...@gmail.com> > wrote: > >> Hello, >> >> First of all, I have been using CMake for a few years now, it is awesome >> tool, thank you. >> >> The only problem I currently have with CMake is its language, which has >> not really intended to be one. After reading a few endless discussions >> about this topic, I decided to give it a try and do something practical. >> >> My current design is using Python as an extension for the regular >> CMakeLists.txt files: if there is a CMakeLists.py file, it would be loaded. >> >> It should not be too hard to maintain, the current API design uses only >> 1-3 function that should be implemented in cmake. >> >> For more information, see the [closed] merge request #389 >> <https://gitlab.kitware.com/cmake/cmake/merge_requests/389>. >> >> I would be happy to hear your opinion about this idea. >> > > Hello Shmuel, > > what do you find fault with the CMake language? I have my own complaints > about it, which may be completely orthogonal or even contradictory to yours. > > I am currently refactoring cmCommand and the way commands are interpreted > in the CMake language. This refactoring will simplify porting the CMake > language frontend to a different scripting engine. I have spent some > thoughts on this and I have a very strong opinion about the direction. > > To avoid another "language X is better than Y" discussion, I will not go > into more details. You should elaborate your motivation first. > > cheers, Daniel >
-- 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