I’m going to use git for a project of mine and instead of parsing git’s output (which is the adviced way to use it from your application), I thought I’d rather use libgit and link to it. The first step was getting rid of autohell and moving to CMake.
This patch against git’s current master branch includes the CMakeLists.txt file and a few modifications to the source (mostly due to the different way variable replacement works in autotools vs CMake).
So far, only libgit, libxdiff and git are built. Will I go go for the other binaries (gitweb, gitk, etc)? I’m not sure, as I’m not interested but it shouldn’t be difficult to CMake-ize those.
I think the move from autotools to CMake could be very useful for the msysgit* developers, as they no longer would depend on MSys*
* I have not tried to build git on Windows with my CMakeLists.txt yet, I’ll do it tomorrow
** It’s not actually true yet: I run two bourne shell-scripts but I could easily rewrite those in CMake, too.
Update I’ve produced a new patch, as the old one did not perform a few needed renames
Let the deautomakifaction continue. 🙂
Unless things have changed since the last time this came up (doubtful), libgit is *not* intended for consumption by anybody but git itself, and the API is not guaranteed to remain at all stable. On the other hand, the plumbing commands in git are guaranteed to remain stable because that’s the intended API for scripts and other clients to use to access git.
I’m working on a git tool too (in Qt), but using the command-line interface. The Git developers have been very vocal in discouraging the use of libgit.a, since it is an internal library and subject to arbitrary changes. They state that the command-line interface is the only stable API. If you have your heart set on libgit, I’d certainly recommend wrapping it in a local API, so that you can make necessary changes for later releases.
Kevin, Paul: the problem with libgit is not that the interface might be unstable, but that you get nonsensical results when calling functions twice. This is because quite a lot of data structures are initialized at program startup, and never again.
And Ian, you missed the mark completely: we do not use automake at all.
Things is, we still rely on MSys for the shell scripts, and that will not change very soon, as there are quite large ones left (not to speak of the Perl scripts).
But I find it laudable to have CMake, as this does not leave the poor souls stuck with MSVC behind.
As far as I am concerned, I will not pay Microsoft any more than I already did, and that means that I am stuck with MSys/MinGW, and I have to admit that I am quite happy with it.
Oh, and BTW this commenting scheme sucks. I cannot post from my text-only browser, because it does not even show me the _links_ to the captcha images. Not nice.
Thanks for pointing that out.
I will not use libgit.a directly but through a Qt wrapper I’m going to write. I’ll take are of cleaning up data structures in the Qt wrapper.
I tried once to port git to CMake and MSVC thanks to the CMake glob feature. I did not go very far because git is full of posixism, which is fair but fine for MSVC. If you succeed (and I hope you will), this sure will become very interesting to me.
Dscho, FYI, you don’t have to pay anything to use the express edition of MSVC2008.
@Abdel: I’ve tried to build Git using my CMakeLists.txt (which is missing some special-casing for Windows, I’ll add that eventually) and the KDE Win32 implementation of POSIXisms for MSVC. There are still missing things but much less. Also, note there is a “compat” directory in git which includes the source for some Linuxisms.
Aha! I didn’t know about this KDE layer, thank you! So you are going to make this a dependency of git on Windows? Or include it in your repository?
I’ll try to compile when you publish them (and when I find the time).
@Abdel: no, I’m not going to make my git-CMake stuff depend on KDEWin32. If any, I would include that in my repository. However, my point is having a git library C++ applications (maybe C) can use easily, not porting git to Windows.
if possible, please try to get this upstream, would be one more nice switching to cmake 🙂