Re: [Chicken-users] CMake tarballs

[Brandon J. Van Every]

felix winkelmann wrote:

> Oh, and don't tell people on this list to contribute to something other
> than Chicken, please! ;-)

Heh!  All will henceforth contribute to automagical Chicken packaging 
systems.


> Indeed, Windows builds are the main reason why I think CMake is so 
> useful.
> There were times when I thought Windows is a homogenous platform - 
> Boy, was
> I wrong: MSVC, MinGW, Cygwin, ... It's a mess, built around an operating
> system that isn't exactly broken, but doesn't give any decent support for
> development either. UNIX is a mess as well, sure, but it's messyness 
> is older,
> and people have put a lot of brain into finding a solution (autotools) 
> that
> works, most of the time.

Autotools could have solved Windows build problems eons ago.  The Free 
Software Foundation does not want it to happen.  They want Windows to 
die, and anything that uses VC++ to die.  They are intensely political, 
and I didn't appreciate the depth of this until I got on the Autoconf 
mailing list a few years ago.  Their phrase, "It would harm the GNU 
Project" spoke volumes to me.

The FSF has benefited the world with a lot of tools, and has caused 
things to happen that otherwise wouldn't have happened.  But they've 
also had blind spots due to their politics.  Other open source 
developers who don't entirely believe in their ideology have moved into 
the niches they don't want to be part of.  Linux, CMake, and Eclipse are 
all examples of this.  Yes Linux is GPLed, yes it's 80% GNU tools.  But 
organizationally, Linus Torvaldis got something done that RMS never got 
done with the GNU Hurd.  People who want results move beyond pure 
ideology.  It's good what the FSF has given the world, but I sure don't 
care to work with them.  They want all software licenses to be ideology 
and social movement.  They are opposed to people making their own 
business decisions and just developing things that work.  So 
fortunately, there are other open source cultures and we don't require 
the FSF for everything.

CMake solves the problem that the FSF won't solve.  The reason CMake 
isn't more popular is because Autoconf has such a huge installed base.  
But I think in the next decade, Autoconf will be seen as increasingly 
archaic.  More projects will move to better build systems, CMake or 
otherwise.

> > >  CMake isn't even a "usual" solution for Windows.
> >
> >  Neither is Chicken.  Nor Darcs.
>
> You do have a point here. The reason is that Windows has no "usual" 
> solution,
> Windows is a non-developer platform.

Well, Visual Studio, VC++, and C# are "usual."  But what of it?  They're 
also limited.  Windows development culture is end user centric.  This 
can make it rather painful for developers.  On the other hand, you have 
a lot more options for commodity hardware support.  That's one thing 
that Windows does do a lot better than any of the Linux distros I've 
seen.  A lot of the functional programming crowd I hang out with in 
Seattle prefers Macs.  They offer the power programmer stuff + far 
better ease of use for devices and stuff.  You pay for it though, and 
it's almost irrelevant as a consumer gaming platform.  I hang out on 
Windows only because I think I'm going to ship games on it.


> >  And there's the Dart Dashboard stuff for testing and web reportage, if
> > anyone's actually interested enough in that to do the work.  I'm more
> > concerned with OpenGL at present, and would like others to step up 
> > for such
> > things.  The offer from Kitware to do the server-side hosting is there
> > though.
>
> Yes, it's there and I'm really pleased by their offer. Still, a 
> non-dashboard,
> fully chicken-based testing method is what I personally prefer, to be 
> honest,
> to allow things like comparing benchmark results, etc.

Sure, fine, whatever.  Someone do the work.  You said you didn't want 
to, and I don't want to either.  I want someone else to do some heavy 
lifting so I can get on with OpenGL stuff.  Which I've had a damn hard 
time getting started on this past week, because it isn't the same CMake 
drill I've been doing for 9 months.


> >  Finally, the CMake guys give real support and assistance with their 
> > stuff.
> > I've not worked with a more responsive open source team.  I went with 
> > CMake
> > as much for the people as the technology.  In contrast, the GNU crowd is
> > exceedingly difficult to work with, full of polemics.  I offered to wrap
> > VC++ for them once, using code from 2 different available open source
> > solutions.  They refused.  "It would harm the GNU Project," they said.
>
> There are polemics everywhere, in the UNIX world as in the Windows world.
> There are polemics on this mailing list. I'm a polemic myself.

There are degrees of it, and you can't hold a candle to the GNU bigots, 
frankly.  I'd like to see you try.


> And I say it again: autotools SUCKS SUCKS SUCKS. It's hideous, m4 is
> brain-damaging, thousand-line shellscripts are sick, fighting with
> autotools-versions is annoying, and reading the official book
> ("GNU Autoconf, Automake and Libtool", New Riders) has left me with
> the impression
> that the people who created it are enormously experienced UNIX hackers
> who really
> know every corner of the UNIX world and know absolutely nothing about 
> software
> engineering or even writing maintainable code. But perhaps it's just a 
> personal
> problem of mine: Shellcode makes me want to close my eyes and think of
> something differently.

You're not alone.  Schemers have a high percentage chance of having a 
sense of aesthetics.  Common Lispers have less aesthetic sense, but 
still an order of magnitude more than most Java, C#, or C++ 
programmers.  Autoconf is waaaaaay beneath these.  All that can be said 
for it, is it works on Unix and it's deployed everywhere.

> But what are the alternatives? What we need is a build environment 
> that works
> everywhere, is widely available and makes people actually want to build
> the package with it. CMake is *not* there yet, but nearly so. 

CMake's weak spots:

- it's just a bunch of library calls, not a language per se.  So you 
type LONG_WINDED_STUFF WITH_UNDERSCORES.  On the positive side, these 
calls actually do a helluva lot for you.  I do agree with William 
Hoffman: having a nice language doesn't matter.  Having the guts do the 
things you need them to do is what matters, and this is why CMake beat 
SCons for KDE's attention span.  So, tedium of the "language" ends up 
being a minor issue.

- the freely available documentation sucks.  Meaning, it's haphazard, 
incomplete, and at times terse.  But I'm as guilty as the next 
programmer as far as not doing anything about it.  I need to deliver 
programming, not documentation.  Responsiveness on the mailing list more 
than makes up for substandard free documentation.  Maybe the book you 
can buy is better, but they develop stuff so fast, and I know how to 
keep abreast, that I haven't seen fit to buy the book.  Anyways, I 
consider the free documentation to be "the serious major problem with 
CMake."  If I find myself needing to train a bunch of people in CMake, 
I'll do something about it.  Until then, hey, I went up the learning 
curve and I know what's going on.


Cheers,
Brandon Van Every