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