[Tux4kids-tuxtype-dev] Branches and conflicts and git, oh my!

[David Bruce]

Hi Brendan,

> but it "branched" the existing branches
> under each project. Not pretty. In hindsight it would have been more than
> sufficient to leave the t4kcommon project under root and branch the trunk of
> each project making use of it, separately.

Agree - I think it might not be very feasible to merge e.g.
tux4kids/tuxmath/trunk and
tux4kids/branches/commonification/tuxmath/trunk using svn's merging
feature.  I had a painful experience merging Sarah's GSoC tuxtype
branch with tuxtype's trunk.

> As it is, stuff is so messy right now that I'm not convinced it's even
> salvageable.

I wouldn't go that far - I think libt4k-common is fine.  Last time I
worked on it (maybe two months ago), I had gotten it to build with
autotools as a shared libtool library, and it seemed to install
properly and make a valid tarball with "make dist".  I didn't get
tuxmath to successfully link with it, however, even though the library
appeared to be installed.  However, I pretty much just left it at that
point without any detailed troubleshooting and moved on to other
stuff.

Once someone figures out the linking problem, I would think we could
just start by having the main trunk of tuxmath link to t4k-common but
not actually use it, and then convert one source file at a time to use
the functions in t4k-common instead of e.g. SDL_extras.c.  We could
look at the commonification branch of tuxmath for reference, but not
actually do a svn merge with it.

> In any case, when the dust has settled, here's what I recall remains to be
> done before adopting the common lib (maybe I've missed something):
> -Testing on Win32 and Mac
> -Building/using dynamic (shared) libs
> -Decide on dealing with t4kcommon being unavailable
>
> I think David had mentioned preferring a shared lib to a static one. Was
> there a specific reason for that? Distribution requirements, perhaps?

Yes - the distros really seem to dislike static libs, although what
they really are trying to avoid is having multiple packages each have
their own copy of e.g. libSDL statically linked into the binary.
libt4k-common might be acceptable as a static lib because it belongs
exclusively to our program and is less likely to be used by others.
Nonetheless, if eventually tuxmath, tuxtype, and tuxpaint all use
libt4k-common, I strongly suspect that the distros would want it
packaged separately.

The autotools build of libt4k-common is the first time I've used
libtool, but AFAICT the process is almost identical for building a
shared or static lib, with just a slightly different entry in the
Makefile.am - libtool takes care of the rest.

> The
> extra complexity would mean some additional headaches, I think, especially
> on other platforms.

I have no problem with making libt4k-common a static lib for win32 and
OSX, if it turns out to be easier.


> Oh, git: I've been using git in school, and my experience has been that it's
> _much_ (much!) faster and (after a learning curve) more friendly to merge
> conflicts.

I've been using git-svn for tux4kids for the last several months,
meaning I use git for everything local and git-svn to sync with our
repository.

fwiw, my family is out of town for the next 4 days, giving me an
opportunity to put in more time on this stuff than I've had for a
while.

Best,

David