Re: [PATCH/RFC] Build a shared / renamed / "stable" version of the library?

[A Large Angry SCM <gitzilla@gmail.com>]

Matthias Urlichs wrote:
> Build (and use) libgit.so instead of libgit.a.
> 
> --- 
> 
> I have written this nice Python extension that gives me fast access to
> git objects. Python extensions are built as shared libraries. Linking
> shared and non-shared objects into one library results in a couple of
> linker warnings on i386; other architectures are far less forgiving.
> 
> So the best choice I seem to have is to build a shared libgit.so.
> 
> Unfortunately, libgit doesn't have nice symbol names. I dunno how you
> all would feel about a big patch which renames absoutely every foo()
> function in libgit to be git_foo() instead (or one that #ifdef's them)...
> so I'm taking the easy way out, and use versioned symbols. That should
> prevent symbol name conflicts with other libraries.
> 
> I've had to redefine usage(), error() and die() to git_*(), because
> they're just too conflict-ish. "error" is even a weak symbol in libc. :-/
> 
> To summarize, the choices seem to be:
> - don't do anything => no script language extensions, need to fork off
>   a git program for absolutely everything. Bah.
> - build libgit.a with -fpic'd objects => doesn't work on all
>   architectures.
> - build libgit.shared.a and use that for building script language
>   extensions => works now, but may cause name conflicts down the road.
> - build a "normal" libgit.so => ditto on the name conflicts.
> - build a libgit.so with symbol versions => no name conflicts expected,
>   but works only with the GNU linker.
> - rename all library functions and globals => quite a bit of work,
>   and more typing down the road.
> - add "#define foo git_foo" to all library functions => ugly.
> 
> Opinions?

Renaming all the library functions and globals is the way to go if the 
long term view is that Git functionality will be desired in other 
projects. This is my view.

However, it's not clear (to me, anyway) that libgit is structured (other 
than naming) in a way that's usable for non core-git tools; git-daemon 
was discussed recently. Some research needs to be done to answer this 
question.