[CMake] CMake IR

Wed Jul 29 09:25:51 EDT 2015

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