Re: [Chicken-users] CMake tarballs

[felix winkelmann]

On 7/30/06, Brandon J. Van Every <address@hidden> wrote:
>  Is your resistance based on actually using the CMake build?  Tell me what's
> broken about the build, not how you can't be bothered to download a CMake
> package.  Generally, in open source, when some people do large things of
> general benefit, other people are expected to do small things for personal
> benefit.  That's the calculus of how anything gets done.

I don't think Toby called the build "broken", but for a UNIX developer,
the canonical way of building a package is "./configure;make;make install"
and any change in that means some getting used to. It will come, once
cmake gets more attention.

But configuring and building software is something that can get annoying
quickly, as we all have surely experienced, so I can understand anybody
who gets sensitive when a time-proven build step does something that moves
away from the usual path, even if superior (I like ccmake, for example. It
has a few quirks, but it is a good idea).

> I, for one, am not interested in making Chicken even more obscure by
> requiring an obscure build tool.
>
>  CMake 2.4.2 is readily obtained in various Linux distros.  That's not every
> Unix out there but it's a lot of 'em.  If your Unix doesn't have a packaging
> system, perhaps you should contribute your open source energies to one.

But cmake is not a standard component yet. That can be a problem. On the
other hand it builds fine on all platforms I have access to.

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

>  Emphasizing "every" while leaving out MSYS and VC++ - particularly the
> latter - is just Unix bigotry.  The fact of the matter is, half the world
> uses VC++ for stuff.  Having a build that handles all versions of VC++,
> without needing to write separate special stuff, is advantageous to
> Chicken's future.  Heck, in the CMake universe, sometimes I have to
> entertain VC++ yokels who don't think Unix is very important, that CMake
> should just orient itself around handling all the different flavors of VC++
> because that's so inherently useful.  Fortunately, the CMake developers know
> what the term "cross-platform" means, so VC++ bigots and Unix bigots are
> never taken seriously.

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.

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

> >  Exactly. Why would I want to install CMake so I can build on a system
> > that actually allows me to have a real build environment.
>
>  What you mean is a Unix build environment.  BTW there are other build
> cultures out there.  Aside from Autotools and CMake, SCons and Ant are
> notable ones.  Someone was even working on a Chicken SCons thingy, about the
> time I got started with CMake.  I have not heard anything about that in
> awhile, so I assume it was either abandoned or not much effort is being put
> into it.

The SCons stuff was about building programs compiled with Chicken, not Chicken
itself, IIRC.


>  When you raise trivial objections, it is called "stop energy."  Here's a
> RFC on stop energy:
> http://www.userland.com/whatIsStopEnergy  Being a proponent
> of Stop Energy is not something to be proud of.

Please lets not start accusing each other. Lets keep this technical, ok?

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

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

>  Do you realize that the reason I got started on CMake in the first place is
> because Felix felt the ./configure build... well, how shall I put this...
> sucked?  Like, it was written by somebody else, he didn't know what was
> going on with it, didn't really want to know, and said if he could do it
> over he would.  So 9 months ago I ran with that.  Now we are where we are
> today.

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.

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. Tt is
technically better than autotools,
but it still has to become a standard solution, has to get acceptance, has to
be the base of high-profile software (and KDE, if everything goes according to
plan, will be exactly that) and has to burn itself into the minds of developers
everywhere.

>  Chucking autotools will be a fantastic move when the CMake build has
> proven, after a very long testing period, that it does everything the
> autotools did, only better.  I'd say that will take 6..12 months of testing
> in the field.  That's not heavy handedness, that's due caution.

Right, autotools will be chucked when cmake has proven itself and when it has
become a "standard" build tool. Chucking a working autotools-based build just
because the CMake build is technically better or more elegant would be crazy,
of course.

I want people to use Chicken, and make it as easy as possible to build and
install it, and any way of making it more convenient is important. Once,
autotools, makefile.vc, makefile.dj was the most convenient way. The it
was autotools and makefile.vc. Now its autotools and CMake. In the future
it will hopefully be only CMake. But that future isn't there yet.

The build-environment is just a means to infiltrate people's computers with
Chicken, and whatever makes it easier for them, and whatever can be maintained
with less effort (an important reason, as I have real problems understanding
the autotools stuff) is the way to go.

So, to make things clear:

- CMake is the better solution (and many thanks for making it possible, Brandon)
- autotools is the standard solution on UNIX, unfortunately - but we
will help with
 spreading the CMake word
- autotools support will *not* be dropped in the near future, but it
will probably
 (and hopefully) be used less and less


cheers,
felix


--
http://galinha.ucpel.tche.br:8081/blog/blog.ssp