[CMake] CMake IR

Wed Jul 29 06:02:52 EDT 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150729/e43d65fd/attachment.html>