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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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] [Discussion] Add python support for CMakeLists

(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

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

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] [Discussion] Add python support for CMakeLists

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] [Discussion] Add python support for CMakeLists

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

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