[Tux4kids-discuss] libt4kcommon update

[Brendan Luchen]

Hi David,

I know I've been quiet the past few days, so I just wanted to touch
base. I've been dividing my time between frantically getting
physically set up (I can type email with a full-sized keyboard again!)
and looking at build systems--fooling around with the autotools,
getting intimately familiar with our setup, and comparing it with the
CMake chain. 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, so by going the CMake route, it may even be
cleaner to use some hacks and workarounds to make it
packager-friendly.

A couple of questions:
What actually constitutes being packager-friendly? Is it a very
platform-dependent question? Are there guidelines on what kind of
metadata/organization is needed? Or should I be asking someone else
;)?

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. If a static lib could possibly make itself useful, then it's
worth the small amount of extra baggage--but I don't quite see how it
might be, except potentially making the lives easier of users who want
to build from scratch.

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. But it just
occurred to me that it might be a better idea to just leave it up to
the user to have libt4kcommon installed, presumably through the
package manager. I'm not sure whether that would help or harm the
possibility of a versioning/compatibility nightmare. What do you
think?

Phew. That's longer than I expected. Copying the list.

Best,
Brendan