Re: [CMake] CMake IR

[Nicolas Desprès]

On Thu, Jul 30, 2015 at 1:51 PM, Nagy-Egri Máté Ferenc 
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

[Bill Hoffman]

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

[Nagy-Egri Máté Ferenc via CMake]

@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, a

Re: [CMake] CMake IR

[Domagoj Saric]

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

[Nicolas Desprès]

On Wed, Jul 29, 2015 at 2:51 PM, Nagy-Egri Máté Ferenc 
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

Re: [CMake] CMake IR

[Bill Hoffman]

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

[David Cole via CMake]

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

Re: [CMake] CMake IR

[David Cole via CMake]

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

Re: [CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

Hi Matt,




I also posted this idea to the dev list at the same time, but it’s awaiting 
moderation due to the inserted links.




The project you reference is very similar indeed. It facilitates the consuming 
of CMake for IDEs, but it does not help in integrating it. Unaffecting the 
internals of CMake (which end-users don’t really care about anyway) is both 
good and bad at the same time. IDEs consuming this stateless representation of 
a build help them being a back-end on their own right, but does not help 
interacting with the build. Introducing a new source file in the IDE still 
could only be done by altering the script files (by the IDE or the user).




This kind of integration is what CLion is doing, but I’m not sure I would be 
happy with the kind of features they present here, namely that the IDE ‘plays 
along’ with someone who comments out critical parts of the generated script. 
The IDE should have a chance at interacting with CMake at a lower level, that 
is CMake understanding it’s own generated stuff you mentioned. But if it would 
understand it, why not use it internally?






Feladó: Matt McCormick
Elküldve: ‎szerda‎, ‎2015‎. ‎július‎ ‎29‎. ‎14‎:‎58
Címzett: Nagy-Egri Máté Ferenc
Másolat: cmake@cmake.org





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

Re: [CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

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

Re: [CMake] CMake IR

[Matt McCormick]

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

[Nicolas Desprès]

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



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

Re: [CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

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

Re: [CMake] CMake IR

[Raymond Wan]

Hi Máté,


On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri Máté Ferenc  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

[CMake] CMake IR

[Nagy-Egri Máté Ferenc via CMake]

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