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

2017-01-13 Thread 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

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

2017-01-13 Thread 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

[cmake-developers] [ANNOUNCE] CMake 3.7.2 available for download

2017-01-13 Thread Robert Maynard
We are pleased to announce that CMake 3.7.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! - Changes in 3.7.2 since 3.7.1: Aleix

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

2017-01-13 Thread 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

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

2017-01-13 Thread 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

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

2017-01-13 Thread 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

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

2017-01-13 Thread 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

[cmake-developers] Fwd: Creating a Keil uVision generator

2017-01-13 Thread Marco Schuler
From: Marco Schuler Date: 2017-01-12 11:16 GMT+01:00 Subject: Re: [cmake-developers] Creating a Keil uVision generator To: Paul Wilkinson Hi all 2017-01-03 0:27 GMT+01:00 Paul Wilkinson : > Hi all, > >

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

2017-01-13 Thread 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

Re: [cmake-developers] deprecate check_function_exists?

2017-01-13 Thread Brad King
On 01/11/2017 03:59 PM, Stephen Sorley wrote: > So, could check_function_exists() be explicitly deprecated in the > documentation in favor of check_symbol_exists()? Yes. Please submit a MR with proposed documentation updates. There may still be use cases for the test that

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

2017-01-13 Thread 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

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

2017-01-13 Thread 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

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

2017-01-13 Thread 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

Re: [cmake-developers] [RFC] Fastbuild generator

2017-01-13 Thread comic fans
I hope I've known this earlier so I can do less... and I'll goto your branch and join gitter channel to discuss . On Mon, Jan 9, 2017 at 5:12 PM, Charles Huet wrote: > Hi, > > I ported the work of @inbilla to CMake trunk a few months ago, and fixed > quite a few tests on

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

2017-01-13 Thread 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

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

2017-01-13 Thread 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,

Re: [cmake-developers] deprecate check_function_exists?

2017-01-13 Thread Stephen Sorley
Thanks Brad, I've created the merge request here: https://gitlab.kitware.com/cmake/cmake/merge_requests/394 -Stephen Sorley On Thu, Jan 12, 2017 at 9:44 AM, Brad King wrote: > On 01/11/2017 03:59 PM, Stephen Sorley wrote: > > So, could check_function_exists() be

[cmake-developers] install/local/fast and install/strip/fast are not fast

2017-01-13 Thread Mike Gelfand
Hello everyone, Didn't trace back when this happened, but for quite a long time now install/local/fast and install/strip/fast targets, at least when using "Unix Makefiles" generator, are not at all fast. They depend on install/local and install/strip targets respectively instead of

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

2017-01-13 Thread 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

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

2017-01-13 Thread 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