[Tux4kids-tuxtype-dev] libt4kcommon update

[David Bruce]

Hi Brendan,

> The more I see, the more I am convinced that it would be
> a good move to migrate from autotools if at all possible. The
> impression I get is that the autotools paradigm has a rich tradition
> in hacks and workarounds,

Err, could you be a little more specific?

> so by going the CMake route, it may even be
> cleaner to use some hacks and workarounds to make it
> packager-friendly.

My knowledge of CMake is admittedly pretty rudimentary, but I can
think of many advantages of autotools off the top of my head:
1. Lots of useful (and essential) built-in targets - make install,
make uninstall, make dist, make distcheck, make dist-bz2, and so
forth.  CMake doesn't even provide a built-in method to install or
create tarballs (I believe CPack is the packaging tool).
2. No need for any special build tools on the user's machine - just
"./configure; make; make install".  While it is just as simple to type
"cmake; make", it does require the user to have CMake.
3. Very simple for distro packagers - they are very familiar with
autotools packages, so the procedure to make, say, an RPM package is
very well-described.  Similarly, it is simple to write a MacPorts
portfile for an autotools-using project.

The biggest *valid* drawback of autotools, IMHO, is that being a GNU
project, there is little interest in native Windows support.

There is also a lot anti-autotools sentiment that in my opinion comes
from them having a long learning curve.  Autoconf and Automake are not
hard to use, but I do think they are hard to learn how to use.


> Static library--any use for one? It's nearly simple as ticking a box
> to support dynamic vs. static, but it sounds like dynamic is what's
> expected.

I agree.  The one exception is in the mingw-cross-env build, where
everything is static, resulting in a single large executable.  But for
use on linux, I think a dynamic (shared) library is the right way to
do this.

>
> Another thing I find important is preserving the ability to build TM
> and TT from only their respective repos--as opposed to needing the
> t4kcommon tree as well, if libt4kcommon is added as a dependency. I've
> been pondering how best to to that, possibly by keeping a latest and
> greatest build of the library in both games' trees.

At least with autotools, for those building from source they just have
to first go to the t4kcommon tree, do "./configure; make; sudo make
install", then cd to the tuxmath or tuxtype tree and do the same.
Once these are packaged, the package manager will handle installing
the t4kcommon package if the user does "sudo apt-get install tuxmath".

So, basically I don't yet see the advantage to be gained from
switching to CMake, other than making it much easier to do a native
Windows build.

Regards,

David