Re: linking libgit.a in C++ projects

[cte <cestreich@gmail.com>]

On Thu, Jul 31, 2008 at 3:57 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:
>> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather
>> than being lame and parsing the output the various git commands, I'm
>> using libgit.a to provide all of the needed functionality for my app.
>
> Don't do that! libgit.a is an internal library used solely to build
> git binaries. It means that its interface can be cahnged at any time.
> Though, there is an idea of creating the real git library that other
> applications can use, but AFAIK no one is working on it. So parsing
> output is the only correct solution right now. In fact, it is not
> difficult to do, because most plumbing commands are rather flexibly
> in what they output and how.

I'm not worried about the interfaces changing; the gui is tied to a
particular version of git, and I will update the code that calls into
libgit I pull new changes from the mainline into my local clone. Also,
who's to say that the output of the various commands won't change
formats with future releases of git? There is no correct solution if
you are worried about forward compatibility, unless a well defined API
is created (which would be sweet btw, but is probably not a priority).

>> However, the git source uses a few reserved C++ keywords; namely
>> 'typename', and 'new'.
>
> Because this source code are meant to be compiled by C and not by C++!
> Even if we will have real git library for other applications to use,
> it still be compiled only by C. Thus, C++ keywords are not issue.

Clearly ;)

Fortunately, g++ can compile C programs and link static libraries that
were compiled by C compilers, unless of course, they use C++ keywords.
I don't think it is unreasonable to rename the _very few_ C++ keywords
in git's source in the interest of allowing C++ projects to leverage
libgit.