[cmake-developers] [Discussion] Add python support for CMakeLists

[Shmuel H,]

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 <daniel at pfeifer-mail.de>
wrote:

> On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, <shmuelhcmake at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170112/ea81294b/attachment.html>