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

[Florent Castelli]

> 
> It's up to users to use generator expressions instead of if(WIN32) or 
> whatever:
> 
> add_library(foo
>   foo.cpp
>   $<$:foo_win.cpp>
> )
> 
> This has been possible for years and was designed with IDEs in mind:

Sure, it’s possible, but it’s not very user friendly or declarative (you need 
to parse and interpret the generator expression).

> 
> http://public.kitware.com/pipermail/cmake-developers/2014-September/023042.html
> 
>> I find that most of the conditionals are just to create the list of
>> sources per platform and then the list of dependencies. It’s certainly
>> possible to use generator expressions for some cases, but they don’t have
>> the prettiest syntax around, and maybe also not access to all the local
>> variables that you need to pick the right files.
> 
> You should be able to put any configure-time variable through the generator 
> expressions $ or $ to make them genex-compatible.

Same, it’s not user friendly or a great syntax.
I’ve rarely seen any advanced usage in projects in the wild, I think for that 
very reason.

One thing that I dislike in genex is that there is no “else” clause.
So you have to duplicate the whole condition and add a $ around it.
Having something close to a ternary operator would be nice.

/Florent
-- 

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

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

[Stephen Kelly]

Florent Castelli wrote:

> Well, CMake scripts can be written in a somewhat declarative form now.
> What prevents this now is that a lot of people use indirections
> everywhere. For example: add_library(foo STATIC ${SRCS}) If it was a plain
> list, any decent IDE would be able to parse this and add another file to
> the list easily. If some commands allowed more expressive alternative
> forms, it would definitely improve the situation:
> 
> add_library(foo STATIC
>   bar1.c
>   bar2.c
>   WINDOWS
>   windows-specific.c
>   APPLE
>   apple-specific.m
> )

It's up to users to use generator expressions instead of if(WIN32) or 
whatever:

 add_library(foo
   foo.cpp
   $<$:foo_win.cpp>
 )

This has been possible for years and was designed with IDEs in mind:

 http://public.kitware.com/pipermail/cmake-developers/2014-September/023042.html

> I find that most of the conditionals are just to create the list of
> sources per platform and then the list of dependencies. It’s certainly
> possible to use generator expressions for some cases, but they don’t have
> the prettiest syntax around, and maybe also not access to all the local
> variables that you need to pick the right files.

You should be able to put any configure-time variable through the generator 
expressions $ or $ to make them genex-compatible.

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

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

[Brad King]

On 01/16/2017 03:40 PM, Florent Castelli wrote:
> Well, CMake scripts can be written in a somewhat declarative form now.
[snip]
> I made some functions with parameters similar to the example above and
> everything became a (custom) declarative format. 

Yes, many projects have macros/functions to achieve exactly that.
This shows that a preferred form for editing the spec, even for
humans, is a declarative format.  In the above cases that format is
stored inside `CMakeLists.txt` files or loaded by them.  This is
consistent with my proposal for a generalized declarative spec
that is loaded by the procedural language for evaluation.

-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

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

[Florent Castelli]

Well, CMake scripts can be written in a somewhat declarative form now.
What prevents this now is that a lot of people use indirections everywhere. For 
example: add_library(foo STATIC ${SRCS})
If it was a plain list, any decent IDE would be able to parse this and add 
another file to the list easily.
If some commands allowed more expressive alternative forms, it would definitely 
improve the situation:

add_library(foo STATIC
  bar1.c
  bar2.c
  WINDOWS
  windows-specific.c
  APPLE
  apple-specific.m
)

I find that most of the conditionals are just to create the list of sources per 
platform and then the list of dependencies. It’s certainly possible to use 
generator expressions for some cases, but they don’t have the prettiest syntax 
around, and maybe also not access to all the local variables that you need to 
pick the right files.

In my company, I got annoyed by all the people who just copy pasted CMake files 
(in imperative form) around without understanding what was everything doing, so 
I made some functions with parameters similar to the example above and 
everything became a (custom) declarative format. 
It had the benefit of fixing all the copy issues around (that was just annoying 
boilerplate) and introduce some interesting sanity checks:
 - checking that all the files in the source folder are used (so we don’t miss 
a header for IDE users for example or leave stray files around)
 - checking that all the include folders exist (this prevents some spelling 
mistakes)
 - checking that all the include folders are relative and don’t go back in the 
hierarchy or aren’t absolute (for a cleaner project structure and preventing 
undeclared dependencies between targets)
 - checking for dependency cycles (and erroring on them), CMake tolerates this, 
not my coding standards (btw, it’s fun to write graph DFS algorithms in the 
CMake language)
 - translating “Framework::Foobar” to the right calls to find the frameworks 
and link against it without more boilerplate
 - translating “FOO::FOO” to a find_package() call and using the imported 
target automatically in some circumstances
All of that was done because CMake has a powerful scripting language, so it’s 
definitely interesting to have one!

Maybe CMake doesn’t need a real declarative mode, it just needs a small set of 
user friendly functions that does the same thing as the low level ones and can 
be easily edited by IDEs?

/Florent

> On 16 Jan 2017, at 21:02, Shmuel H,  wrote:
> 
> > My point is that an IDE should be able to edit the declarative spec
> > without having run a configuration or even create a build tree.  The
> > spec should be the preferred form for making changes and stored in
> > version control.  Any intermediate spec generated by a procedural
> > Language script cannot serve this role.
> 
> I understand that. Maybe we should let the user decide whether to use the 
> advantages the declarative spec or to use a script to generate it. That way, 
> we would not lose the scripting future, which is a big future of CMake. On 
> the other side, we would not force users to use that and even we would make 
> it a lot easier for IDEs to manage these projects.
> -- 
> 
> 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

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

[Shmuel H,]

> My point is that an IDE should be able to edit the declarative spec
> without having run a configuration or even create a build tree.  The
> spec should be the preferred form for making changes and stored in
> version control.  Any intermediate spec generated by a procedural
> Language script cannot serve this role.

I understand that. Maybe we should let the user decide whether to use the
advantages the declarative spec or to use a script to generate it. That
way, we would not lose the scripting future, which is a big future of
CMake. On the other side, we would not force users to use that and even we
would make it a lot easier for IDEs to manage these projects.
-- 

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

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

[Brad King]

On 01/14/2017 03:27 AM, Shmuel H, wrote:
>  1. Script stage: Look for and run build script, that will generate a
> [JSON] configuration file.

My point is that an IDE should be able to edit the declarative spec
without having run a configuration or even create a build tree.  The
spec should be the preferred form for making changes and stored in
version control.  Any intermediate spec generated by a procedural
language script cannot serve this role.

-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

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

[Shmuel H,]

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  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

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

[Dāvis Mosāns]

2017-01-12 11:48 GMT+02:00 Charles Huet :
[...]
> Lua is the language that should be used, since it is easy to embed on all
> the platforms CMake supports. All arguments about language X being better
> than language Y do not matter, since all other languages do not answer to
> the constraints that are CMake's, which are, as I understand them:
> - being embeddable so as to not depend on the user to install something else
> - support for lots of various platforms (e.g. ARM)
>

Lua isn't only option, there is also [1] mruby (embedded Ruby)
compiles to C library which can be statically linked. It also is very
customizable, you can compile only those features which you need.


[1] https://github.com/mruby/mruby
-- 

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

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

[Shmuel H,]

I think that the special thing about CMake, is the option to customize a
build system (if needed). This is also the thing that makes CMake harder to
use than other declarative-based build systems.

Therefore, I think we should combine these things together:

   - From one side, we would have (for example) a global list of targets
   with the option to export it to (for example) a JSON document and then
   simply load it.
   - From the other side, programmers should be able to use a script
   language to customize their build process.

That would enable programmers, IDEs and automated tools to create a valid
and simple documents for simple projects and also would give programmers
the power they need in order to customize cmake for their needs.

For example, a simple declaration (pseudo code):
cmake_libraries += {
   ["name":  "myLib",
"files": "myLib.c",
"link_type": "static"]
}

And a customized script for easily adding a library for a cpp class:
def my_add_library(name, class_name):
cmake_libraries += {
   ["name":  name,
"files": [class_name +
'.cpp', class_name + '.h'],
"link_type": MY_LINK_TYPE]
}

# Then, add my customized library:
 my_add_library('myLib', 'myLib')

Note that it still would be possible to export these "scripted files" to a
simple JSON file.

I would be happy to hear your opinion about this general design.


On Fri, Jan 13, 2017 at 5:56 PM, Brad King  wrote:

> On 01/12/2017 01:20 PM, Shmuel H, wrote:
> > maybe a general problem with dependencies, which generally
> > make our life harder?
>
> Yes.  People typically install CMake only in order to build something else.
> If Python were added as an external dependency then that would be yet
> another step.  If it were bundled then our bootstrap script and CMake-based
> build of CMake itself would both have to learn to build Python.  Python
> is also a distribution in addition to a language, so deploying it raises
> the question of what to bundle with it.  None of these is something I'd
> like to have added to the responsibilities of maintaining and distributing
> CMake.
>
> There are already other build systems that use Python as their language,
> but many people still choose CMake over them anyway.
>
> > However, for me - a user, a known and well-designed programming language
> > for CMake would be very helpful. I can't say that for every other user,
> > but I think it would make their life a lot easier too.
>
> As Charles Huet mentioned Lua is a good choice because it provides a
> language and is portable to everywhere that has C.  It is also not a
> distribution.  I've posted in the past a design for a cmake_lua command
> that allows one to use Lua code within CMakeLists.txt files.  Actually
> using it as a full replacement language though will first require more
> refactoring internally as I mentioned in my previous post.
>
> As I've mentioned in previous discussions, if we're going to go through
> a language change we should make sure it addresses important needs.
> Having a declarative specification that can be externally tooled will
> be helpful to IDEs.  I'd envision such a format that is then imported
> by the procedural-language part of the configuration process for
> evaluation of conditions and finalization for the current target.
>
> Without a comprehensive design I'm hesitant to proceed on any such effort.
>
> -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

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

[Egor Pugin]

> One requirement for such a format is
> that it is possible for a tool to read the entire spec, make small
> modifications, and write it back out as close as possible to the
> original format.

I have such yaml formatting function for my layout.
You may see those pretty specs I've posted.
At the moment it lacks of some deep nodes formatting, but the overall
structure is preserved. See [1].

> This means a standard layout would need to be defined.

And my current layout [2] (from that function too).

[1] https://github.com/cppan/cppan/blob/master/src/common/yaml.cpp#L171
[2] https://github.com/cppan/cppan/blob/master/src/common/yaml.cpp#L196

On 13 January 2017 at 19:15, Brad King  wrote:
> On 01/13/2017 11:05 AM, Egor Pugin wrote:
>> Why not just use C/C++ for writing build system (bs) rules?
>>
>> CMake first will build bs itself (e.g. into shared library) and then
>> load and execute it on the source tree.
>
> In an earlier post of this thread I said that no dynamic loading will
> be allowed.  We used to have the `load_command` command but it is now
> deprecated.  This approach simply doesn't work because we can't know
> that the toolchains can compile for CMake's architecture on the host.
> Certainly we're not going to include a C++ JIT in CMake itself ;)
>
>> I'll investigate this in my C++ Archive Network [1] project very soon.
>> Now I have mentioned here declarative (YAML) syntax with custom CMake
>> insertions. For example, see specifications [2-5].
>
> YAML may be a nice choice for a declarative spec, especially because
> it can just contain JSON too.  One requirement for such a format is
> that it is possible for a tool to read the entire spec, make small
> modifications, and write it back out as close as possible to the
> original format.  The idea is that "git diff" should only show the
> changes made by the tool.  This means a standard layout would need
> to be defined.
>
> -Brad
>



-- 
Egor Pugin
-- 

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

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

[Konstantin Podsvirov]

Hello all! 13.01.2017, 18:56, "Brad King" :On 01/12/2017 01:20 PM, Shmuel H, wrote: maybe a general problem with dependencies, which generally make our life harder?Yes. People typically install CMake only in order to build something else.If Python were added as an external dependency then that would be yetanother step. If it were bundled then our bootstrap script and CMake-basedbuild of CMake itself would both have to learn to build Python. Pythonis also a distribution in addition to a language, so deploying it raisesthe question of what to bundle with it. None of these is something I'dlike to have added to the responsibilities of maintaining and distributingCMake.There are already other build systems that use Python as their language,but many people still choose CMake over them anyway. I believe that language should be one. Many of us well know C ++, and so we understand each other.   However, for me - a user, a known and well-designed programming language for CMake would be very helpful. I can't say that for every other user, but I think it would make their life a lot easier too.As Charles Huet mentioned Lua is a good choice because it provides alanguage and is portable to everywhere that has C. It is also not adistribution. I've posted in the past a design for a cmake_lua commandthat allows one to use Lua code within CMakeLists.txt files. Actuallyusing it as a full replacement language though will first require morerefactoring internally as I mentioned in my previous post.As I've mentioned in previous discussions, if we're going to go througha language change we should make sure it addresses important needs.Having a declarative specification that can be externally tooled willbe helpful to IDEs. I'd envision such a format that is then importedby the procedural-language part of the configuration process forevaluation of conditions and finalization for the current target.Without a comprehensive design I'm hesitant to proceed on any such effort. I completely agree. Must first be designed very, very good design decision. -Brad-- Powered by www.kitware.comPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake Consulting: http://cmake.org/cmake/help/consulting.htmlCMake Training Courses: http://cmake.org/cmake/help/training.htmlVisit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.htmlFollow this link to subscribe/unsubscribe:http://public.kitware.com/mailman/listinfo/cmake-developers  Regards,Konstantin Podsvirov -- 

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

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

[Brad King]

On 01/13/2017 11:05 AM, Egor Pugin wrote:
> Why not just use C/C++ for writing build system (bs) rules?
> 
> CMake first will build bs itself (e.g. into shared library) and then
> load and execute it on the source tree.

In an earlier post of this thread I said that no dynamic loading will
be allowed.  We used to have the `load_command` command but it is now
deprecated.  This approach simply doesn't work because we can't know
that the toolchains can compile for CMake's architecture on the host.
Certainly we're not going to include a C++ JIT in CMake itself ;)

> I'll investigate this in my C++ Archive Network [1] project very soon.
> Now I have mentioned here declarative (YAML) syntax with custom CMake
> insertions. For example, see specifications [2-5].

YAML may be a nice choice for a declarative spec, especially because
it can just contain JSON too.  One requirement for such a format is
that it is possible for a tool to read the entire spec, make small
modifications, and write it back out as close as possible to the
original format.  The idea is that "git diff" should only show the
changes made by the tool.  This means a standard layout would need
to be defined.

-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

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

[Egor Pugin]

Hi,

Why not just use C/C++ for writing build system (bs) rules?
C++ is for those who have modern compilers. (By C++ I mean modern C++11-14-17).
C is for everything. These two apis can coexist.

CMake first will build bs itself (e.g. into shared library) and then
load and execute it on the source tree.

I'll investigate this in my C++ Archive Network [1] project very soon.
Now I have mentioned here declarative (YAML) syntax with custom CMake
insertions. For example, see specifications [2-5].

[1] https://cppan.org/
[2] https://cppan.org/pvt.cppan.demo.sqlite3/version/3.16.1/specification
[3] 
https://cppan.org/pvt.cppan.demo.unicode.icu.i18n/version/58.2.0/specification
[4] https://cppan.org/pvt.cppan.demo.webp/version/0.5.1/specification
[5] 
https://cppan.org/pvt.cppan.demo.boost.conversion/version/1.62.0/specification

On 13 January 2017 at 18:56, Brad King  wrote:
> On 01/12/2017 01:20 PM, Shmuel H, wrote:
>> maybe a general problem with dependencies, which generally
>> make our life harder?
>
> Yes.  People typically install CMake only in order to build something else.
> If Python were added as an external dependency then that would be yet
> another step.  If it were bundled then our bootstrap script and CMake-based
> build of CMake itself would both have to learn to build Python.  Python
> is also a distribution in addition to a language, so deploying it raises
> the question of what to bundle with it.  None of these is something I'd
> like to have added to the responsibilities of maintaining and distributing
> CMake.
>
> There are already other build systems that use Python as their language,
> but many people still choose CMake over them anyway.
>
>> However, for me - a user, a known and well-designed programming language
>> for CMake would be very helpful. I can't say that for every other user,
>> but I think it would make their life a lot easier too.
>
> As Charles Huet mentioned Lua is a good choice because it provides a
> language and is portable to everywhere that has C.  It is also not a
> distribution.  I've posted in the past a design for a cmake_lua command
> that allows one to use Lua code within CMakeLists.txt files.  Actually
> using it as a full replacement language though will first require more
> refactoring internally as I mentioned in my previous post.
>
> As I've mentioned in previous discussions, if we're going to go through
> a language change we should make sure it addresses important needs.
> Having a declarative specification that can be externally tooled will
> be helpful to IDEs.  I'd envision such a format that is then imported
> by the procedural-language part of the configuration process for
> evaluation of conditions and finalization for the current target.
>
> Without a comprehensive design I'm hesitant to proceed on any such effort.
>
> -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



-- 
Egor Pugin
-- 

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

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

[Brad King]

On 01/12/2017 01:20 PM, Shmuel H, wrote:
> maybe a general problem with dependencies, which generally
> make our life harder?

Yes.  People typically install CMake only in order to build something else.
If Python were added as an external dependency then that would be yet
another step.  If it were bundled then our bootstrap script and CMake-based
build of CMake itself would both have to learn to build Python.  Python
is also a distribution in addition to a language, so deploying it raises
the question of what to bundle with it.  None of these is something I'd
like to have added to the responsibilities of maintaining and distributing
CMake.

There are already other build systems that use Python as their language,
but many people still choose CMake over them anyway.

> However, for me - a user, a known and well-designed programming language
> for CMake would be very helpful. I can't say that for every other user,
> but I think it would make their life a lot easier too. 

As Charles Huet mentioned Lua is a good choice because it provides a
language and is portable to everywhere that has C.  It is also not a
distribution.  I've posted in the past a design for a cmake_lua command
that allows one to use Lua code within CMakeLists.txt files.  Actually
using it as a full replacement language though will first require more
refactoring internally as I mentioned in my previous post.

As I've mentioned in previous discussions, if we're going to go through
a language change we should make sure it addresses important needs.
Having a declarative specification that can be externally tooled will
be helpful to IDEs.  I'd envision such a format that is then imported
by the procedural-language part of the configuration process for
evaluation of conditions and finalization for the current target.

Without a comprehensive design I'm hesitant to proceed on any such effort.

-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

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

[Shmuel H,]

Hello Bard,

First of all, let me show my appreciation for an open source maintainer
that open for changes which is not a obvious.

The problem with a solution that doesn't add another language as a
dependency is that it creates incompatibility and requires installing of
more components in order to achieve a working system (e.g. Install Python,
Install a program that communicates with CMake Server, etc) which creates
the complete opposite of the "almost universal-compatible build system" the
CMake project has been able to achieve until now.

I'm interested in your reason behind the decision not to add Python as a
dependency: is that a licencing problem, a problem specific about Python,
or maybe a general problem with dependencies, which generally make our life
harder?

However, for me - a user, a known and well-designed programming language
for CMake would be very helpful. I can't say that for every other user, but
I think it would make their life a lot easier too.

Kind regards,
Shmuel.

On Thu, Jan 12, 2017 at 4:27 PM, Brad King  wrote:

> On 01/11/2017 04:23 PM, Shmuel H, wrote:
> > a few endless discussions about this topic
>
> Previous discussions have not ended in a new language being integrated,
> but that does not mean they failed.  Several challenges w.r.t. the
> internal architecture were identified.  A lot of progress has been made
> in addressing some of those, but there is more work to do.  The goal is
> to separate the representation of the build system model that is fed to
> the generators from the current CMake language implementation.  Once that
> is done then other approaches/languages can be added to build the model
> instead of using the current language exclusively.
>
> > 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.
>
> We'd rather not introduce Python as a dependency of CMake's distribution,
> even optionally.  It may be reasonable to have optional support when Python
> can be found at runtime.  However, any such approach would need to avoid
> requiring dynamic loading of plugins into CMake or any kind of stable
> C++ API to be maintained.
>
> Since previous such discussions we've now had the cmake-server mode
> introduced.  It allows programs written in any language to communicate
> with CMake through a JSON protocol.  Currently the protocol is very
> minimal and geared toward IDEs that want to get a representation of the
> build system after configuration of a build tree.
>
> A similar approach could be used to interact with external processes
> during configuration.  Such a protocol would allow programs written
> in any language to be used for defining CMake build systems.
>
> Previous discussions have also identified the value of having a declarative
> specification format.  This is largely orthogonal to the procedural
> language
> that drives the configuration process because any such language could still
> have a command/step that loads the declarative part.
>
> -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

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

[Jean-Michaël Celerier]

(My simple user opinion):

I'm not a fan of the idea.
Not particularly because of Python, but because with this, now
if I want to use a library that someone made with a CMakeLists.py in my
project
(for instance as a submodule) :
* I also have to install Python on the machines where the build happens,
* tell my users to install Python,
* add it to their PATH...

Many already have trouble just installing and running CMake, and this adds
another
potential layer of complexity, and a fragmentation of the ecosystem.
Unless CMake would ship with its own Python interpreter ?

I know, this is a non-problem on Linux and OS X (or is it ? On my machine
/usr/bin/python is python 3 but on others it is python 2),
but there are some poor people out there stuck with Windows machines, and I
wouldn't like their lives to be even harder.

Best regards
Jean-Michaël

On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H,  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
> .
>
> I would be happy to hear your opinion about this idea.
>
> Best regards,
> Shmuel H.
>
> --
>
> 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/opensou
> rce/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

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

[Shmuel H,]

Hi Jean,

If that would be implemented, a python (or any other language) interpreter
would be included in CMake. However, Brad have a problem with that approach.

On Thu, Jan 12, 2017 at 7:28 PM, Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> (My simple user opinion):
>
> I'm not a fan of the idea.
> Not particularly because of Python, but because with this, now
> if I want to use a library that someone made with a CMakeLists.py in my
> project
> (for instance as a submodule) :
> * I also have to install Python on the machines where the build happens,
> * tell my users to install Python,
> * add it to their PATH...
>
> Many already have trouble just installing and running CMake, and this adds
> another
> potential layer of complexity, and a fragmentation of the ecosystem.
> Unless CMake would ship with its own Python interpreter ?
>
> I know, this is a non-problem on Linux and OS X (or is it ? On my machine
> /usr/bin/python is python 3 but on others it is python 2),
> but there are some poor people out there stuck with Windows machines, and
> I wouldn't like their lives to be even harder.
>
> Best regards
> Jean-Michaël
>
> On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, 
> 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
>> .
>>
>> I would be happy to hear your opinion about this idea.
>>
>> Best regards,
>> Shmuel H.
>>
>> --
>>
>> 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

Re: [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 
wrote:

> On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H, 
> 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
>> .
>>
>> 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

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

[Brad King]

On 01/11/2017 04:23 PM, Shmuel H, wrote:
> a few endless discussions about this topic

Previous discussions have not ended in a new language being integrated,
but that does not mean they failed.  Several challenges w.r.t. the
internal architecture were identified.  A lot of progress has been made
in addressing some of those, but there is more work to do.  The goal is
to separate the representation of the build system model that is fed to
the generators from the current CMake language implementation.  Once that
is done then other approaches/languages can be added to build the model
instead of using the current language exclusively.

> 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.

We'd rather not introduce Python as a dependency of CMake's distribution,
even optionally.  It may be reasonable to have optional support when Python
can be found at runtime.  However, any such approach would need to avoid
requiring dynamic loading of plugins into CMake or any kind of stable
C++ API to be maintained.

Since previous such discussions we've now had the cmake-server mode
introduced.  It allows programs written in any language to communicate
with CMake through a JSON protocol.  Currently the protocol is very
minimal and geared toward IDEs that want to get a representation of the
build system after configuration of a build tree.

A similar approach could be used to interact with external processes
during configuration.  Such a protocol would allow programs written
in any language to be used for defining CMake build systems.

Previous discussions have also identified the value of having a declarative
specification format.  This is largely orthogonal to the procedural language
that drives the configuration process because any such language could still
have a command/step that loads the declarative part.

-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

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

[Charles Huet]

Hi,

I also worked on a similar prototype, and I think this should be discussed
further and set as a long-term goal for CMake.

The conclusions from the last time this came up were (from the top of my
head):

1)
Lua is the language that should be used, since it is easy to embed on all
the platforms CMake supports. All arguments about language X being better
than language Y do not matter, since all other languages do not answer to
the constraints that are CMake's, which are, as I understand them:
- being embeddable so as to not depend on the user to install something else
- support for lots of various platforms (e.g. ARM)

2)
This needs refactoring in CMake core that are ongoing (and some of this is
also needed for the cmake server if I understand correctly) but far from
finished.


The biggest problem I see is that there is no official stance from Kitware
on this subject.


Le mer. 11 janv. 2017 à 23:52, Shmuel H,  a écrit :

> 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
> .
>
> I would be happy to hear your opinion about this idea.
>
> Best regards,
> Shmuel H.
> --
>
> 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

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

[Daniel Pfeifer]

On Wed, Jan 11, 2017 at 10:23 PM, Shmuel H,  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
> .
>
> 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

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

[Shmuel H,]

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
.

I would be happy to hear your opinion about this idea.

Best regards,
Shmuel H.
-- 

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