<div dir="ltr">Hi Daniel,<div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Regards, </div><div>Shmuel.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 12, 2017 at 12:16 PM, Daniel Pfeifer <span dir="ltr"><<a href="mailto:daniel@pfeifer-mail.de" target="_blank">daniel@pfeifer-mail.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, <span dir="ltr"><<a href="mailto:shmuelhcmake@gmail.com" target="_blank">shmuelhcmake@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>First of all, I have been using CMake for a few years now, it is awesome tool, thank you.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>It should not be too hard to maintain, the current API design uses only 1-3 function that should be implemented in cmake.</div><div><br></div><div>For more information, see the [closed] merge request <a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/389" target="_blank">#389</a>.</div><div><br></div><div>I would be happy to hear your opinion about this idea.</div></div></blockquote><div><br></div></span><div>Hello Shmuel,</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>To avoid another "language X is better than Y" discussion, I will not go into more details. You should elaborate your motivation first.</div><div><br></div><div>cheers, Daniel<br></div></div></div></div>
</blockquote></div><br></div></div>