Re: [hackers-il] Freecell Solver's Test Suite + Conversion to CMake
- Hi all!
All hail my new sig. I replaced my old one that was mis-understood in several
ways due to being taken out of its original context.
On Monday 04 August 2008, Nadav Har'El wrote:
> On Mon, Aug 04, 2008, Shlomi Fish wrote about "Re: [hackers-il] Freecell
Solver's Test Suite + Conversion to CMake":
> > 1. Its files are written in a consistent high-level language, whose
> > interpreter is written in C++. This is instead of Autoconf's
> > m4-generating-Bourne-shell setup, where both m4 and /bin/sh are quirky
> > and get broken very easily.
> The whole idea of Autoconf's "m4-generating-Bourne-shell setup" is that
> the result (the bourne shell) can run on any computer without needing to
> install anything. Therefore, whatever input language your autoconf
> alternative has, generating Bourne shell from it is a *good* idea, I
Bourne shell (and especially the one generated from Autoconf) is very
limiting, error-prone, and tends to break a lot. I recall many times when I
needed to tweak ./configure scripts by hand due to a bug or limitation there.
So it's not a good idea to rely on it. If I can:
1. Make sure I have prepared more consistent, usable and high-level (e.g:
CMake, Perl, Python, etc.) framework.
2. Make sure that it is portable enough.
3. Require the user to install it there.
4. This in turn will run the "./configure" stage and possibly other stages.
It will save a lot of future frustrations on my and my user's part.
> So, if CMake doesn't generate Bourne shell, does it mean your users will
> need to install it before they can compile your code? Don't you consider
> this a problem?
Yes, the users will need to install it before they compile my code. But it's a
simple matter, and then they can enjoy CMake for life with all the programs
that require it (see http://www.cmake.org/Wiki/CMake_Projects ).
So I don't consider it a problem. Forcing one to rely on the least common
denominator that is pre-installed on all UNIX-like systems is a bit absurd in
this day and age.
> See more on this below.
> > 2. Configuration and compilation are much faster than in Autoconf,
> > yielding a faster development process.
> This surprises me. Compilation speed really has nothing to do with autoconf
> - CMake can't make gcc (or whatever) any speedier. And while running
> "configure" for the first time isn't very quick, normally running for the
> second time is indeed quick (because autoconf caches its results).
Maybe it just feels faster, or the makefiles are less bloated, and don't have
the long GCC command line. Don't know. I'm doing some stuff that's not
> > 6. It merges in the functionality of Automake and libtool, both in a more
> > consistent and less error-prone way.
> Sounds interesting. Like I said, I'm not a big automake fan, so indeed I'd
> like to see a better approach .
> > 9. Has native support for Win32.
> What is Win32? Who uses that system anyway? :-)
A few people, apparently. It's a priority for me, and for many other FOSS
> > 10. Since CMake is installed separately on the system, the source
> > pacakges are smaller. I was able to reduce the size of the FCS tar.gz
> > from over 500,000 bytes to slightly above 200,000 bytes.
> What does this matter?
> As a user, given the choice between downloading an extra 300,000 bytes
> (which takes a few seconds on today's internet) and having to install an
> entire package I don't have (CMake), I'd definitely prefer the first
CMake is only one package, and it's probably avialable from your
distribution's sources (or else they won't be able to build KDE 4). And you
can save the extra 350,000 bytes (possibly more as more Autoconf
functionality is there) times and again when downloading source packages and
their new versions. A stitch in time saves nine.
Shlomi Fish http://www.shlomifish.org/
What Make Software Apps High Quality - http://xrl.us/bkeuk
Shlomi, so what are you working on? Working on a new wiki about unit testing
fortunes in freecell? -- Ran Eilam