Re: [Tuxpaint-devel] [Tux4kids-tuxtype-dev] Branches and conflicts and git, oh my!
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: David B. <dav...@gm...> - 2009-12-27 01:49:32
|
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 |