Re: linking libgit.a in C++ projects

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Jul 31, 2008, 12:34 UTC
Message-ID: <20080731123406.GG7008@dpotapov.dyndns.org>
In-Reply-To: <20080731111446.GO32184@machine.or.cz>

On Thu, Jul 31, 2008 at 01:14:46PM +0200, Petr Baudis wrote:

Show 8 quoted lines

> 
> I don't think this is that big a problem; there are applications that
> are doing this already, e.g. cgit, and if you tie your application to
> a particular git version by for example making git a submodule of your
> source, this is pretty safe; it will just mean that you will have to
> do some non-trivial porting of your code to the new interface each time
> you update - but I think large changes in the interface are pretty rare
> in practice by now, and there shouldn't be much on the horizon either(?).

What you see as large changes depend on how well you know git internals. Git develops very quickly and if someone who is trying to use libgit.a does not follow git development closely, it may happen pretty soon that even not so big changes will become a huge problem to accomadate them. As result, the program may stick with an old Git version, and that puts users of this program in the situation where they cannot use their favorite frontend with new repositories.

> What would be the reason to disallow C++ users? The costs aren't that
> high, and (modulo, say, extern "C" { }) there should be no C-C++
> compatibility issues, right?

I mean that putting extern "C" { } around should be sufficient to use this library in C++. But I see now some current headers contains some C++ keywords and that causes the problem. So, yes, those headers should be corrected if they become part of external available API. I am not sure whether it makes sense to correct them now, but there are only three places where C++ keywords are used:

diff.h:135:extern int diff_tree_sha1(const unsigned char *old, const diff.h:137:extern int diff_root_tree_sha1(const unsigned char *new, object.h:38:extern const char *typename(unsigned int type);

So, the patch should not be large, and it is up to Junio to decide what to do about it.

Dmitry