Re: [CMake] CMake IR
On Thu, Jul 30, 2015 at 1:51 PM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: [...] @Nicolas: Yes, these tools indeed have been working for the past few decades. Others also suggested why don’t I generate CMakelists.txt instead? The problem is that the current limitations of CMake all originate from the way the workflow is organized. Multi-configuration makefiles are trivial to implement if you do them by hand. All targets append the architecture after their name (app-x86, app-x64, lib-x86, etc.) and there were all-x86 and all-x64 targets, and there were the usual “all” target that references all-x86, all-x64. In CMake the workflow is baked into selecting an architecture at the earliest points in the configuration process and stores it as a global variable (state!) which then shoots all multi-configuration generators in the knee. Yes, it is possible to remove this limitation from CMake, but it would take roughly a year. Holding onto this limitation alone just because it is historically the way how CMake has been designed immediately rules it out from ~75% of application development going on in the world in the future (mobile app devel), which is funny because building cross-platform mobile apps is the future, and this is just the market that could benefit of CMake the most. I always used CMake for generating Makefile targeting a single architecture. I tried few times to generate Visual Studio project and XCode project and my first impression was quite good. But I have not a lot of experiences in this area. I agree with you that the users will need multi architecture support more in the future. -- Nicolas Desprès -- 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
Re: [CMake] CMake IR
On 7/30/2015 7:51 AM, Nagy-Egri Máté Ferenc via CMake wrote: Bill: I am a member, I just tried sending using the same mail using the “secret CC” option. It seems it did not work. OK, I just checked and it was rejected because of this: Reason: Message has implicit destination I have approved it, but if you could send directly to the list that would be better as I don't look at the rejected posts that often. -Bill -- 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
Re: [CMake] CMake IR
@Domagoj: “In addition to it feeling like working with (or fighting against) an ugly crossover between a C preprocessor and a shell script from 1979, an increasingly big source of frustration is its rigidness and limitation of 'only one toolset/compiler per project'.” I couldn’t have put it any better myself. Indeed, I recently had the idea of writing a Windows Store XAML application to give a GUI frontend to TagLib, just as an excercise and give it a jump start in August on my vacation when I want to do something productive. I started collecting the dependencies and everything, and came across… CMake has Windows Store support, but how on Earth am I going to build x86/x64/ARM targets from one VS solution? I was reading the docs a while and said to mysef “ah, f*ck it, no CMake has nothing to do here.” It is very annoying that CMake has these limitation at it’s very core that would take months and months to rule out. I can imagine Android being even more painful in this regard. CMake really could do a whole lot better in this. @Nicolas: Yes, these tools indeed have been working for the past few decades. Others also suggested why don’t I generate CMakelists.txt instead? The problem is that the current limitations of CMake all originate from the way the workflow is organized. Multi-configuration makefiles are trivial to implement if you do them by hand. All targets append the architecture after their name (app-x86, app-x64, lib-x86, etc.) and there were all-x86 and all-x64 targets, and there were the usual “all” target that references all-x86, all-x64. In CMake the workflow is baked into selecting an architecture at the earliest points in the configuration process and stores it as a global variable (state!) which then shoots all multi-configuration generators in the knee. Yes, it is possible to remove this limitation from CMake, but it would take roughly a year. Holding onto this limitation alone just because it is historically the way how CMake has been designed immediately rules it out from ~75% of application development going on in the world in the future (mobile app devel), which is funny because building cross-platform mobile apps is the future, and this is just the market that could benefit of CMake the most. @Bill: I am a member, I just tried sending using the same mail using the “secret CC” option. It seems it did not work. @David: Maybe some convincing and positive feedback can do the trick. I mostly live my life on Windows, so most technologies and tools relate to Windows, but all the HPC clusters I use are linux, hence the need for CMake. My initial research builded down to this: Learn from the ‘competition’ Identify the portable properties of building a C++ application (mostly from CMake) and define an XML Schema. Create the Schema of a chosen compiler Implementing everything in C++ Initially do not bother with a front-end. Using the Schema, Visual Studio can provide Intellisense based on the .xsd file. This is sufficient for dev pourposes. Using this open-source lib, getting a parser/deserializer and datastructure for use in C++ is as easy as 1-2-3. Use the aforementioned lib to get a datastructure and serializer using the MSBuild Schema. Almost done. Just wrap the Schemas of the IR into neat C++ classes. Tadaaa: C++ front-end. Wrap the C++ classes with C++/CX for use with Powershell. Tadaaa: Powershell front-end. Implement everything in PS (just for kicks) PS alread understands the [xml] type and can read/write and process it. Validation can be used from PSCX. Transform the data read into MSBuild’s own. (Somewhat blindly, because there are no neat classes available in the MSBuild Schema format) Amost done. Write PS5 classes around the Schema entities. Tadaaa: PS front-end. Future work: Make it better Implement other generators after the all too convenient, XML based MSBuild. Add Unit Test Schemas Add packaging Schemas (Nuget is again XML based with XSD Schema, trivial to implement) Enhance package support to be able to fetch dependencies from git and build (a la Cargo), have installation method similar to CMake packages, etc. If the entire build’s information is available as an iterable C++ tree-like datastructure, how hard can it be to implement generators like Ninja? (Not trivial, but not hard either.) If there is a clear Schema of valid options for a specific feature, so many things simplify. Again, imagine automatic fetching of dependencies from multiple repositories even. Nuget, GitHub, .deb, you name it! And I haven’t even mentioned things like remote builds and what not… all new features could be introduced as a seperate Schema with it’s respective options, and if the user references the schema in the IR, and the generator supports it, it is done. Imagine distributed builds similar to Incredibuild, but with CMake. Nothing is needed, but the user define a pool of machines,
Re: [CMake] CMake IR
Hi Máté, On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said: “The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.” I'm not much of an expert wih CMake but when someone says I have not found a single person alive..., I would usually counter by asking how many people you've asked? :-) Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. I for one am quite happy with CMake. We can point fingers at technology (i.e., which programming language is better or worse), but in the end, it's really the community support (IMHO). And if I'm stuck with CMake, I can usually find answers to most of my problems on this e-mail list or by searching Google. If you want to refactor CMake along these lines: There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) I have a question for you. Why introduce them as CMake 4.0? Why not start a new project from scratch and give it a new name. Why take over the name of an already working tool? I mean, it's like complaining about Perl (apologies to Perl lovers...just an example!) and wanting to rewrite it from scratch. Up to a point, it is better to come up with new name...if you think you can do it better. I honestly don't think CMake is broken. Perhaps it's because I came from Makefiles and then Autotools -- the latter was a nightmare! Perhaps one possible improvement to CMake might be to improve the documentation a bit so that maybe there's more information on how to *write* modules (as opposed to using modules). Ray -- 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
Re: [CMake] CMake IR
Hi Máté, One way of doing would be to write a tool using whatever language you like, reading an input script written in whatever language you like, that generates cmake code. In such case, the modification to cmake would be smaller but not that simple. You can see this thread from the archive for further details: http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html Cheers, Nico On Wed, Jul 29, 2015 at 9:49 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: Dear CMake devs/users, I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said: “The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.” There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake’s own in just about every regard. I came up with an idea presented here: *http://1drv.ms/1MsufbF* http://1drv.ms/1MsufbF Enhancements such a change could bring about: - The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. - (It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.) - It would modularize the internals of CMake in a cleaner fashion - Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently) - Would allow for configure-time validating of compiler-specific options - Use deferred makefile generation by default (making the implementation of tools like Cotire https://github.com/sakra/cotire/ for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process) - Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.) - SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script. While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally. I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I’ve met say they are “happy” CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. Eagerly await the rolling ball. With all due respect, Máté -- 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 -- Nicolas Desprès -- 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
Re: [CMake] CMake IR
How many people have I asked? We are a group of 5, and have several fellows who have drifted off to companies each with their respective dev teams of 5-15 people. General tendency is that everywhere, there is 1 CMake guru, the rest would be better off not touching the scripts, because they do more harm than good. I can believe that someone coming from the autotools or GNU Make find CMake to be a salvation. But someone being used to Visual Studio’s Solution Explorer (and things generally working out-of-the-box) finds hand authoring scripts in a unique language that’s been documented only 2 months ago… Don’t get me wrong, I am an admin and spend a considerable amount of time scripting in various languages. It’s not the fact that I have to touch scripts. It’s the fact that doing so is a pain. The reason I suggested this as a CMake 4.0 feature is because I am the 11th person out of 10 who actually “likes” CMake a bit and cares for it. I’d rather empower a tool I use on a daily basis than spawn an alternative and spend half my life trying to winning the world over. As is the case with operating systems, they have accumulated so much code, there is no point in trying to write a new one, rather than fixing the ones that exist. Every respectable cross-platform project uses CMake and I have no intention of going against that. I’ve neither the resources (time mostly) to do that, neither do I like the fact of spawning ‘yet another build system’ when nothing prevents from enhancing one that is almost perfect. With enough feedback like yours, I might just brew something similar in a few years time (on the expense of my free time). I could do something just like the author of Invoke-Build did and brew something that only I in the entire world would use, even though that in some sense Invoke-Build is far better than GNU Make or NMake in its foundations (being a processor of inter-dependent jobs, and nothing else). I understand your concern with people trying to hijack a community project and alter it to their personal ideals. However the fact that there are people fighting a war for CMake-izing Boost 2.0, and the fact that Boost 1.x failed two attempts at doing so is because the Boost developers were reluctant to pick up CMake as a build system, even though it is superior to Boost Build in every aspect. That too, is a build system used only in Boost, and nowhere else in the world. (I even had an email discussion with the authors of such an attempt. He handed all the working scripts to the devs, all they should’ve do was type cmake.exe ../src, but they did not.) One of the reasons these attempts failed was because of the Boost dev’s love for their ‘own child’ (Boost Build). The other is that CMake is unfriendly for devs. It is better than many others, but worse than many others. When it works, it’s great. But getting it to work is not always as easy as one might like. I had an idea I felt would benefit the community (the CMake community that is), I thought I’d share it as an idea. ps.: I also had an email encounter with the dev of Invoke-Build about cooking up an Invoke-Build back-end to CMake. He had no idea CMake exists, but because he needed a scriptable (from Powershell that is) build system, he cooked up one of his own. If CMake had a PS front-end, maybe a whole bunch of people pick it up who don’t even know it exists because they live outside the cross-platform world. Feladó: Raymond Wan Elküldve: szerda, 2015. július 29. 11:01 Címzett: Nagy-Egri Máté Ferenc Másolat: cmake@cmake.org Hi Máté, On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said: “The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.” I'm not much of an expert wih CMake but when someone says I have not found a single person alive..., I would usually counter by asking how many people you've asked? :-) Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. I for one am quite happy with CMake. We can point fingers at technology (i.e., which programming language is better or worse), but in the end, it's really the community support (IMHO). And if I'm stuck with CMake, I can usually find answers to most of my problems on this e-mail list or by searching Google. If you want to refactor CMake along these lines: There are gazillions of scripting
Re: [CMake] CMake IR
This all seems like a very good idea, and also like it will take an enormous amount of time and effort. I'd like to help, but I have quite limited available time these days. Let us know if there are specific things you need help with in advancing towards an implementation of these ideas. David C. On Wed, Jul 29, 2015 at 6:02 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: How many people have I asked? We are a group of 5, and have several fellows who have drifted off to companies each with their respective dev teams of 5-15 people. General tendency is that everywhere, there is 1 CMake guru, the rest would be better off not touching the scripts, because they do more harm than good. I can believe that someone coming from the autotools or GNU Make find CMake to be a salvation. But someone being used to Visual Studio’s Solution Explorer (and things generally working out-of-the-box) finds hand authoring scripts in a unique language that’s been documented only 2 months ago… Don’t get me wrong, I am an admin and spend a considerable amount of time scripting in various languages. It’s not the fact that I have to touch scripts. It’s the fact that doing so is a pain. The reason I suggested this as a CMake 4.0 feature is because I am the 11th person out of 10 who actually “likes” CMake a bit and cares for it. I’d rather empower a tool I use on a daily basis than spawn an alternative and spend half my life trying to winning the world over. As is the case with operating systems, they have accumulated so much code, there is no point in trying to write a new one, rather than fixing the ones that exist. Every respectable cross-platform project uses CMake and I have no intention of going against that. I’ve neither the resources (time mostly) to do that, neither do I like the fact of spawning ‘yet another build system’ when nothing prevents from enhancing one that is almost perfect. With enough feedback like yours, I might just brew something similar in a few years time (on the expense of my free time). I could do something just like the author of Invoke-Build did and brew something that only I in the entire world would use, even though that in some sense Invoke-Build is far better than GNU Make or NMake in its foundations (being a processor of inter-dependent jobs, and nothing else). I understand your concern with people trying to hijack a community project and alter it to their personal ideals. However the fact that there are people fighting a war for CMake-izing Boost 2.0, and the fact that Boost 1.x failed two attempts at doing so is because the Boost developers were reluctant to pick up CMake as a build system, even though it is superior to Boost Build in every aspect. That too, is a build system used only in Boost, and nowhere else in the world. (I even had an email discussion with the authors of such an attempt. He handed all the working scripts to the devs, all they should’ve do was type cmake.exe ../src, but they did not.) One of the reasons these attempts failed was because of the Boost dev’s love for their ‘own child’ (Boost Build). The other is that CMake is unfriendly for devs. It is better than many others, but worse than many others. When it works, it’s great. But getting it to work is not always as easy as one might like. I had an idea I felt would benefit the community (the CMake community that is), I thought I’d share it as an idea. ps.: I also had an email encounter with the dev of Invoke-Build about cooking up an Invoke-Build back-end to CMake. He had no idea CMake exists, but because he needed a scriptable (from Powershell that is) build system, he cooked up one of his own. If CMake had a PS front-end, maybe a whole bunch of people pick it up who don’t even know it exists because they live outside the cross-platform world. Feladó: Raymond Wan Elküldve: szerda, 2015. július 29. 11:01 Címzett: Nagy-Egri Máté Ferenc Másolat: cmake@cmake.org Hi Máté, On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said: “The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.” I'm not much of an expert wih CMake but when someone says I have not found a single person alive..., I would usually counter by asking how many people you've asked? :-) Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. I for one am
Re: [CMake] CMake IR
Hi Nico, thank you for the idea. That idea occured to me too, trying to generate the CMakelists.txt script from the desired front-end. Having taken a deep dive into XML schemas, hardcore people even criticise W3C XML Schemas for not having a mathematical foundation which make it difficult to reason about backward compatibility of change to the schema. Using the CMake script, a stateful, imperative script language as an intermediate introduces even more threats, than using a not so well defined, but at least stateless datastructure like XML. Seeing that people want this idea as a seperate project more than a part of CMake, I thought of: defining the XML Schema of building a C++ application defining the XML Schema of a particluar compiler toolchain write a front-end in a script language of choice write a generator for a back-end of choice provide a prototype of a CMakelists.txt XML front-end as a proof-of-concept That way CMakelists.txt files could be used in a completeley alternate toolchain. Feladó: Nicolas Desprès Elküldve: szerda, 2015. július 29. 13:43 Címzett: Nagy-Egri Máté Ferenc Másolat: cmake@cmake.org Hi Máté, One way of doing would be to write a tool using whatever language you like, reading an input script written in whatever language you like, that generates cmake code. In such case, the modification to cmake would be smaller but not that simple. You can see this thread from the archive for further details: http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html Cheers, Nico On Wed, Jul 29, 2015 at 9:49 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: Dear CMake devs/users, I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said: “The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.” There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake’s own in just about every regard. I came up with an idea presented here: http://1drv.ms/1MsufbF Enhancements such a change could bring about: The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. (It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.) It would modularize the internals of CMake in a cleaner fashion Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently) Would allow for configure-time validating of compiler-specific options Use deferred makefile generation by default (making the implementation of tools like Cotire for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process) Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.) SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script. While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally. I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I’ve met say they are “happy” CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. Eagerly await the rolling ball. With all due respect, Máté -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
Re: [CMake] CMake IR
And I wouldn't give up just yet on building support for this into CMake, if not building the entire thing into a future CMake. Perhaps there are valid objections, or perhaps people just need convincing. D On Wed, Jul 29, 2015 at 8:51 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: Hi Nico, thank you for the idea. That idea occured to me too, trying to generate the CMakelists.txt script from the desired front-end. Having taken a deep dive into XML schemas, hardcore people even criticise W3C XML Schemas for not having a mathematical foundation which make it difficult to reason about backward compatibility of change to the schema. Using the CMake script, a stateful, imperative script language as an intermediate introduces even more threats, than using a not so well defined, but at least stateless datastructure like XML. Seeing that people want this idea as a seperate project more than a part of CMake, I thought of: defining the XML Schema of building a C++ application defining the XML Schema of a particluar compiler toolchain write a front-end in a script language of choice write a generator for a back-end of choice provide a prototype of a CMakelists.txt XML front-end as a proof-of-concept That way CMakelists.txt files could be used in a completeley alternate toolchain. Feladó: Nicolas Desprès Elküldve: szerda, 2015. július 29. 13:43 Címzett: Nagy-Egri Máté Ferenc Másolat: cmake@cmake.org Hi Máté, One way of doing would be to write a tool using whatever language you like, reading an input script written in whatever language you like, that generates cmake code. In such case, the modification to cmake would be smaller but not that simple. You can see this thread from the archive for further details: http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html Cheers, Nico On Wed, Jul 29, 2015 at 9:49 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: Dear CMake devs/users, I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said: “The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.” There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake’s own in just about every regard. I came up with an idea presented here: http://1drv.ms/1MsufbF Enhancements such a change could bring about: The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. (It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.) It would modularize the internals of CMake in a cleaner fashion Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently) Would allow for configure-time validating of compiler-specific options Use deferred makefile generation by default (making the implementation of tools like Cotire for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process) Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.) SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script. While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally. I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I’ve met say they are “happy” CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in
Re: [CMake] CMake IR
On 7/29/2015 9:11 AM, Nagy-Egri Máté Ferenc via CMake wrote: I also posted this idea to the dev list at the same time, but it’s awaiting moderation due to the inserted links. We really do not moderate the lists like that. If it is pending it is because you are not a member of the list. So, you should become a member: http://www.cmake.org/mailman/listinfo/cmake-developers Then repost. -Bill -- 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
Re: [CMake] CMake IR
Hi Máté, There is some on-going work along the lines of separating out state. See this thread for more information: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658 You may want to have further discussions on the cmake-developers list. Cheers, Matt On Wed, Jul 29, 2015 at 3:49 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote: Dear CMake devs/users, I wanted to ask your opinion on something that has been troubling me since… well, ever since I started using CMake. I have not found a single person alive who would have said: “The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.” There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake’s own in just about every regard. I came up with an idea presented here: http://1drv.ms/1MsufbF Enhancements such a change could bring about: The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. (It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.) It would modularize the internals of CMake in a cleaner fashion Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently) Would allow for configure-time validating of compiler-specific options Use deferred makefile generation by default (making the implementation of tools like Cotire for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process) Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.) SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script. While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally. I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I’ve met say they are “happy” CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. Eagerly await the rolling ball. With all due respect, Máté -- 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 -- 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
Re: [CMake] CMake IR
On 29.7.2015. 12:02, Nagy-Egri Máté Ferenc via CMake wrote: The reason I suggested this as a CMake 4.0 feature is because I am the 11th person out of 10 who actually “likes” CMake a bit and cares for it. I’d rather empower a tool I use on a daily basis than spawn an alternative and spend half my life trying to winning the world over. My 2 ranting cents: you perfectly summed my own thoughts on CMake. This love-hate relationship seems to be a recurring theme (where you 'adore' the idea behind CMake but 'abhore' the implementation of the idea) so 'there's got to be something to it' :) In addition to it feeling like working with (or fighting against) an ugly crossover between a C preprocessor and a shell script from 1979, an increasingly big source of frustration is its rigidness and limitation of 'only one toolset/compiler per project'. With platforms like Android (NDK) that require you to build for X different architectures with different toolsets/compilers, or IDEs like Xcode or Visual Studio that offer targeting so many different combinations of toolsets and targets (even Android and iOS in the latest version) from a single project having a build system that requires you to create a separate build directory for each and every one of those combinations (and then somehow connect them into a master build where a single CPack invocation will be able to gather and package the build results of all the sub-builds) feels like an ancient torture device. As for the proposal, wouldn't the first logical step in 'decoupling CMake from its legacy' be what Clang did with libclang, i.e extracting the 'core'/non-scripting part of CMake into a libcmake around which new interfaces/DSLs can written/created..? -- Domagoj Saric Software Architect www.LittleEndian.com -- 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
Re: [CMake] CMake IR
On Wed, Jul 29, 2015 at 2:51 PM, Nagy-Egri Máté Ferenc csiga.b...@aol.com wrote: Hi Nico, thank you for the idea. That idea occured to me too, trying to generate the CMakelists.txt script from the desired front-end. Having taken a deep dive into XML schemas, hardcore people even criticise W3C XML Schemas for not having a mathematical foundation which make it difficult to reason about backward compatibility of change to the schema. Using the CMake script, a stateful, imperative script language as an intermediate introduces even more threats, than using a not so well defined, but at least stateless datastructure like XML. I disagree with that statement because I do not see any issue in generating stateful language. autoconf generates shell script. bison, flex, and many others generates C code. Compilers front-end generate IR which is nothing else than a unified assembly language. Compilers back-end generate assembly language for various CPU. Correct me if I am wrong but all those languages are stateful and all thoses generators have been working pretty well for decades. I think the true requirement is whether the language being generated is stable or not. The CMake script language is stable and a lot of effort is spent to keep backward compatibility via policies. [...] -- Nicolas Desprès -- 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
