{"thread":{"id":"1826","subject":"[PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","startedAt":"2005-09-16T12:37:17Z","lastAt":"2005-09-16T21:10:41Z","messageCount":7,"participants":["Matthias Urlichs","A Large Angry SCM","Junio C Hamano","Chuck Lever"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"8675","messageId":"pan.2005.09.16.12.37.14.736570@smurf.noris.de","threadId":"1826","inReplyTo":null,"subject":"[PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-09-16T12:37:17Z","receivedAt":"2005-09-16T12:37:17Z","isPatch":true,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Build (and use) libgit.so instead of libgit.a.\n\n--- \n\nI have written this nice Python extension that gives me fast access to\ngit objects. Python extensions are built as shared libraries. Linking\nshared and non-shared objects into one library results in a couple of\nlinker warnings on i386; other architectures are far less forgiving.\n\nSo the best choice I seem to have is to build a shared libgit.so.\n\nUnfortunately, libgit doesn't have nice symbol names. I dunno how you\nall would feel about a big patch which renames absoutely every foo()\nfunction in libgit to be git_foo() instead (or one that #ifdef's them)...\nso I'm taking the easy way out, and use versioned symbols. That should\nprevent symbol name conflicts with other libraries.\n\nI've had to redefine usage(), error() and die() to git_*(), because\nthey're just too conflict-ish. \"error\" is even a weak symbol in libc. :-/\n\nTo summarize, the choices seem to be:\n- don't do anything => no script language extensions, need to fork off\n  a git program for absolutely everything. Bah.\n- build libgit.a with -fpic'd objects => doesn't work on all\n  architectures.\n- build libgit.shared.a and use that for building script language\n  extensions => works now, but may cause name conflicts down the road.\n- build a \"normal\" libgit.so => ditto on the name conflicts.\n- build a libgit.so with symbol versions => no name conflicts expected,\n  but works only with the GNU linker.\n- rename all library functions and globals => quite a bit of work,\n  and more typing down the road.\n- add \"#define foo git_foo\" to all library functions => ugly.\n\nOpinions?\n\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -47,6 +47,8 @@ ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINE\n \n prefix = $(HOME)\n bindir = $(prefix)/bin\n+libdir = $(prefix)/lib\n+incdir = $(prefix)/include\n template_dir = $(prefix)/share/git-core/templates/\n GIT_PYTHON_DIR = $(prefix)/share/git-core/python\n # DESTDIR=\n@@ -142,7 +144,18 @@ LIB_OBJS = \\\n \tserver-info.o setup.o sha1_file.o sha1_name.o strbuf.o \\\n \ttag.o tree.o usage.o $(DIFF_OBJS)\n \n-LIBS = $(LIB_FILE)\n+ifdef SHARED_LIBOBJ\n+\n+LIB_FILE=libgit.so\n+GITLIB = -L. -lgit\n+\n+else\n+\n+LIB_FILE=libgit.a\n+GITLIB = $(LIB_FILE)\n+\n+endif\n+\n LIBS += -lz\n \n ifeq ($(shell uname -s),Darwin)\n@@ -167,6 +180,7 @@ endif\n ifndef NO_OPENSSL\n \tLIB_OBJS += epoch.o\n \tOPENSSL_LIBSSL = -lssl\n+\tLIBS += -lssl\n else\n \tDEFINES += '-DNO_OPENSSL'\n \tMOZILLA_SHA1 = 1\n@@ -242,7 +256,7 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)) : % \n \t$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n \n git-%: %.o $(LIB_FILE)\n-\t$(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)\n+\t$(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(GITLIB) $(LIBS)\n \n git-mailinfo : SIMPLE_LIB += $(LIB_4_ICONV)\n $(SIMPLE_PROGRAMS) : $(LIB_FILE)\n@@ -267,9 +281,33 @@ $(LIB_OBJS): $(LIB_H)\n $(patsubst git-%,%.o,$(PROGRAMS)): $(LIB_H)\n $(DIFF_OBJS): diffcore.h\n \n+# Use -fPIC for the library files so they may be linked into a shared\n+# library if necessary\n+#\n+ifdef SHARED_LIBOBJ\n+\n+PIC=-fpic\n+\n+$(LIB_FILE): $(LIB_OBJS) libgit.vers\n+\t$(CC) -shared -Wl,-soname,$(SHARED_LIBOBJ) -Wl,--version-script=libgit.vers -o $@ $(LIB_OBJS) $(LIBS)\n+\trm -f $(SHARED_LIBOBJ) && ln -s $(LIB_FILE) $(SHARED_LIBOBJ)\n+\n+else # \"normal\" library\n+\n+PIC=\n+\n $(LIB_FILE): $(LIB_OBJS)\n \t$(AR) rcs $@ $(LIB_OBJS)\n \n+endif\n+\n+# Declare rules for building library files.\n+define lib_rule\n+$1.o: $1.c\n+\t$(CC) $(ALL_CFLAGS) $(PIC) -c -o $1.o $1.c\n+endef\n+$(foreach obj,$(basename $(LIB_OBJS)),$(eval $(call lib_rule, $(obj))))\n+\n doc:\n \t$(MAKE) -C Documentation all\n \n@@ -300,6 +338,14 @@ install: $(PROGRAMS) $(SCRIPTS)\n \t$(MAKE) -C templates install\n \t$(INSTALL) -d -m755 $(DESTDIR)$(GIT_PYTHON_DIR)\n \t$(INSTALL) $(PYMODULES) $(DESTDIR)$(GIT_PYTHON_DIR)\n+ifdef SHARED_LIBOBJ\n+\t$(INSTALL) -m755 -d $(DESTDIR)$(libdir)\n+\t$(INSTALL) -m755 $(LIB_FILE) $(DESTDIR)$(libdir)/$(SHARED_LIBOBJ)\n+\tcd $(DESTDIR)$(libdir) && ln -sf $(SHARED_LIBOBJ) $(LIB_FILE)\n+\t$(INSTALL) -m755 -d $(DESTDIR)$(incdir)\n+\t$(INSTALL) -m755 -d $(DESTDIR)$(incdir)/git\n+\t$(INSTALL) -m644 $(LIB_H) $(DESTDIR)$(incdir)/git\n+endif\n \n install-doc:\n \t$(MAKE) -C Documentation install\n@@ -333,7 +379,7 @@ deb: dist\n ### Cleaning rules\n \n clean:\n-\trm -f *.o mozilla-sha1/*.o ppc/*.o $(PROGRAMS) $(LIB_FILE)\n+\trm -f *.o mozilla-sha1/*.o ppc/*.o $(PROGRAMS) *.a *.so *.so.*\n \trm -f $(filter-out gitk,$(SCRIPTS))\n \trm -f git-core.spec\n \trm -rf $(GIT_TARNAME)\ndiff --git a/cache.h b/cache.h\n--- a/cache.h\n+++ b/cache.h\n@@ -228,6 +228,9 @@ extern int get_sha1_hex(const char *hex,\n extern char *sha1_to_hex(const unsigned char *sha1);\t/* static buffer result! */\n \n /* General helper functions */\n+#define usage git_usage\n+#define error git_error\n+#define die git_die\n extern void usage(const char *err) NORETURN;\n extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));\n extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));\ndiff --git a/debian/changelog b/debian/changelog\n--- a/debian/changelog\n+++ b/debian/changelog\n@@ -1,3 +1,10 @@\n+git-core (0.99.6-2) unstable; urgency=low\n+\n+  * Install a shared libgit.so\n+  * Install development files (git-dev package)\n+\n+ -- Matthias Urlichs <smurf@debian.org>  Wed, 14 Sep 2005 09:04:57 +0200\n+\n git-core (0.99.6-0) unstable; urgency=low\n \n   * GIT 0.99.6\ndiff --git a/debian/control b/debian/control\n--- a/debian/control\n+++ b/debian/control\n@@ -18,9 +18,22 @@ Description: The git content addressable\n  enables human beings to work with the database in a manner to a degree\n  similar to other SCM tools.\n \n+Package: libgit1\n+Architecture: any\n+Depends: ${shlibs:Depends}, ${misc:Depends}\n+Description: The git content addressable filesystem, shared library\n+ This package contains the shared library for git.\n+\n Package: git-tk\n Architecture: all\n Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4\n Description: The git content addressable filesystem, GUI add-on\n  This package contains 'gitk', the git revision tree visualizer.\n \n+Package: git-dev\n+Architecture: any\n+Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4\n+Description: The git content addressable filesystem, development files\n+ This package contains the files needed to build programs which access\n+ the git library.\n+\ndiff --git a/debian/git-core.files b/debian/git-core.files\n--- a/debian/git-core.files\n+++ b/debian/git-core.files\n@@ -1 +1,3 @@\n-/usr\n+/usr/bin\n+/usr/share\n+/usr/lib/*.so.*\ndiff --git a/debian/git-dev.files b/debian/git-dev.files\nnew file mode 100644\n--- /dev/null\n+++ b/debian/git-dev.files\n@@ -0,0 +1,2 @@\n+/usr/include/git\n+/usr/lib/*.so\ndiff --git a/debian/libgit1.files b/debian/libgit1.files\nnew file mode 100644\n--- /dev/null\n+++ b/debian/libgit1.files\n@@ -0,0 +1 @@\n+/usr/lib/libgit.so.1\ndiff --git a/debian/rules b/debian/rules\n--- a/debian/rules\n+++ b/debian/rules\n@@ -25,6 +25,9 @@ else\n \texport MOZILLA_SHA1=YesPlease\n endif\n \n+# build libgit.a with shared objects\n+export SHARED_LIBOBJ=libgit.so.1\n+\n # We do have the requisite perl modules in the mainline, and\n # have no reason to shy away from this script.\n export WITH_SEND_EMAIL=YesPlease\n@@ -60,11 +63,13 @@ install: build\n \tdh_installdirs \n \n \tmake DESTDIR=$(DESTDIR) prefix=$(PREFIX) mandir=$(MANDIR) \\\n-\t\tinstall install-doc\n+\t\tinstall # install-doc\n \n \tmkdir -p $(DOC_DESTDIR)\n \tfind $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'\n \n+\tdh_movefiles -p libgit1\n+\tdh_movefiles -p git-dev\n \tdh_movefiles -p git-tk\n \tdh_movefiles -p git-core\n \tfind debian/tmp -type d -o -print | sed -e 's/^/? /'\ndiff --git a/libgit.vers b/libgit.vers\nnew file mode 100644\n--- /dev/null\n+++ b/libgit.vers\n@@ -0,0 +1,195 @@\n+GIT_1 {\n+\tglobal:\n+\t\tadd_cache_entry ;\n+\t\tadd_packed_git ;\n+\t\tadd_ref ;\n+\t\talloc_filespec ;\n+\t\tbase_name_compare ;\n+\t\tblob_type ;\n+\t\tcache_name_compare ;\n+\t\tcache_name_pos ;\n+\t\tce_match_stat ;\n+\t\tce_path_match ;\n+\t\tce_same_name ;\n+\t\tcheckout_entry ;\n+\t\tcheck_ref_format ;\n+\t\tcheck_sha1_signature ;\n+\t\tcommit_index_file ;\n+\t\tcommit_list_insert ;\n+\t\tcommit_type ;\n+\t\tcount_delta ;\n+\t\tcount_parents ;\n+\t\tcreated_object ;\n+\t\tderef_tag ;\n+\t\tdiff_addremove ;\n+\t\tdiff_change ;\n+\t\tdiffcore_break ;\n+\t\tdiffcore_merge_broken ;\n+\t\tdiffcore_order ;\n+\t\tdiffcore_pathspec ;\n+\t\tdiffcore_pickaxe ;\n+\t\tdiffcore_rename ;\n+\t\tdiffcore_std ;\n+\t\tdiffcore_std_no_resolve ;\n+\t\tdiff_delta ;\n+\t\tdiff_flush ;\n+\t\tdiff_free_filepair ;\n+\t\tdiff_free_filespec ;\n+\t\tdiff_helper_input ;\n+\t\tdiff_populate_filespec ;\n+\t\tdiff_q ;\n+\t\tdiff_queue ;\n+\t\tdiff_queue_is_empty ;\n+\t\tdiff_scoreopt_parse ;\n+\t\tdiff_setup ;\n+\t\tdiff_unmerge ;\n+\t\tdiff_unmodified_pair ;\n+\t\tfill_filespec ;\n+\t\tfill_stat_cache_info ;\n+\t\tfind_pack_entry_one ;\n+\t\tfind_rev_cache ;\n+\t\tfind_sha1_pack ;\n+\t\tfinish_connect ;\n+\t\tfor_each_ref ;\n+\t\tfree_commit_list ;\n+\t\tget_ack ;\n+\t\tget_commit_format ;\n+\t\tget_graft_file ;\n+\t\tget_ident ;\n+\t\tget_index_file ;\n+\t\tget_object_directory ;\n+\t\tget_pathspec ;\n+\t\tget_refs_directory ;\n+\t\tget_ref_sha1 ;\n+\t\tget_remote_heads ;\n+\t\tget_sha1 ;\n+\t\tget_sha1_hex ;\n+\t\tgit_author_info ;\n+\t\tgit_committer_info ;\n+\t\tgit_connect ;\n+\t\tgit_mkstemp ;\n+\t\tgit_path ;\n+\t\thas_pack_file ;\n+\t\thas_pack_index ;\n+\t\thas_sha1_file ;\n+\t\thas_sha1_pack ;\n+\t\thead_ref ;\n+\t\thold_index_file_for_update ;\n+\t\tindex_fd ;\n+\t\tinsert_by_date ;\n+\t\tinstall_packed_git ;\n+\t\tlock_ref_sha1 ;\n+\t\tlookup_blob ;\n+\t\tlookup_commit ;\n+\t\tlookup_commit_reference ;\n+\t\tlookup_commit_reference_gently ;\n+\t\tlookup_object ;\n+\t\tlookup_object_type ;\n+\t\tlookup_tag ;\n+\t\tlookup_tree ;\n+\t\tlookup_unknown_object ;\n+\t\tmark_reachable ;\n+\t\tmatch_refs ;\n+\t\tmkpath ;\n+\t\tnth_packed_object_sha1 ;\n+\t\tnum_packed_objects ;\n+\t\tobject_list_append ;\n+\t\tobject_list_contains ;\n+\t\tobject_list_insert ;\n+\t\tobject_list_length ;\n+\t\tpacked_object_info_detail ;\n+\t\tpacket_flush ;\n+\t\tpacket_read_line ;\n+\t\tpacket_write ;\n+\t\tparse_blob ;\n+\t\tparse_blob_buffer ;\n+\t\tparse_commit ;\n+\t\tparse_commit_buffer ;\n+\t\tparse_date ;\n+\t\tparse_object ;\n+\t\tparse_pack_index ;\n+\t\tparse_pack_index_file ;\n+\t\tparse_sha1_header ;\n+\t\tparse_tag ;\n+\t\tparse_tag_buffer ;\n+\t\tparse_tree ;\n+\t\tparse_tree_buffer ;\n+\t\tparse_tree_indirect ;\n+\t\tpatch_delta ;\n+\t\tpath_match ;\n+\t\tpop_commit ;\n+\t\tpop_most_recent_commit ;\n+\t\tprefix_path ;\n+\t\tprepare_alt_odb ;\n+\t\tprepare_packed_git ;\n+\t\tpretty_print_commit ;\n+\t\tread_cache ;\n+\t\tread_line ;\n+\t\tread_object_with_reference ;\n+\t\tread_rev_cache ;\n+\t\tread_sha1_file ;\n+\t\tread_tree ;\n+\t\trecord_rev_cache ;\n+\t\tremove_cache_entry_at ;\n+\t\tremove_file_from_cache ;\n+\t\trollback_index_file ;\n+\t\trun_command ;\n+\t\trun_command_v ;\n+\t\tsafe_create_leading_directories ;\n+\t\tsafe_strncpy ;\n+\t\tsetup_git_directory ;\n+\t\tsetup_ident ;\n+\t\tsha1close ;\n+\t\tsha1create ;\n+\t\tsha1fd ;\n+\t\tsha1_file_name ;\n+\t\tSHA1_Final ;\n+\t\tSHA1_Init ;\n+\t\tsha1_object_info ;\n+\t\tsha1_pack_index_name ;\n+\t\tsha1_pack_name ;\n+\t\tsha1_to_hex ;\n+\t\tSHA1_Update ;\n+\t\tsha1write ;\n+\t\tsha1write_compressed ;\n+\t\tshow_date ;\n+\t\tsort_by_date ;\n+\t\tsort_in_topological_order ;\n+\t\tsort_list_in_merge_order ;\n+\t\tsq_quote ;\n+\t\tstrbuf_init ;\n+\t\ttag_type ;\n+\t\ttree_type ;\n+\t\tunpack_entry_gently ;\n+\t\tunpack_sha1_file ;\n+\t\tunpack_sha1_header ;\n+\t\tunuse_packed_git ;\n+\t\tupdate_server_info ;\n+\t\tuse_packed_git ;\n+\t\tverify_pack ;\n+\t\twrite_cache ;\n+\t\twrite_ref_sha1 ;\n+\t\twrite_ref_sha1_unlocked ;\n+\t\twrite_rev_cache ;\n+\t\twrite_sha1_file ;\n+\t\twrite_sha1_file_prepare ;\n+\t\twrite_sha1_from_fd ;\n+\t\twrite_sha1_to_fd ;\n+\t\tactive_alloc ;\n+\t\tactive_cache ;\n+\t\tactive_cache_changed ;\n+\t\tactive_nr ;\n+\t\tnr_objs ;\n+\t\tobjs ;\n+\t\talloc_revs ;\n+\t\tnr_revs ;\n+\t\trev_cache ;\n+\t\talt_odb_list ;\n+\t\tpacked_git ;\n+\t\tdiff_queued_diff ;\n+\t\tgit_die ;\n+\t\tgit_usage ;\n+\t\tgit_error ;\n+\tlocal:\n+\t\t*;\n+};\ndiff --git a/t/Makefile b/t/Makefile\n--- a/t/Makefile\n+++ b/t/Makefile\n@@ -8,7 +8,9 @@\n T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)\n \n all:\n-\t@$(foreach t,$T,echo \"*** $t ***\"; sh $t $(GIT_TEST_OPTS) || exit; )\n+\t@$(foreach t,$T,echo \"*** $t ***\"; \\\n+\tenv LD_LIBRARY_PATH=$$(pwd)/..:$$LD_LIBRARY_PATH \\\n+\tsh $t $(GIT_TEST_OPTS) || exit; )\n \t@rm -fr trash\n \n clean:\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nDon't send my boy to Harvard, the dying mother said. Don't send my boy to\nHarvard, I'd rather see him dead.\n"},{"id":"8680","messageId":"432AD981.2080400@gmail.com","threadId":"1826","inReplyTo":"pan.2005.09.16.12.37.14.736570@smurf.noris.de","subject":"Re: [PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-09-16T14:41:05Z","receivedAt":"2005-09-16T14:41:05Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Matthias Urlichs wrote:\n> Build (and use) libgit.so instead of libgit.a.\n> \n> --- \n> \n> I have written this nice Python extension that gives me fast access to\n> git objects. Python extensions are built as shared libraries. Linking\n> shared and non-shared objects into one library results in a couple of\n> linker warnings on i386; other architectures are far less forgiving.\n> \n> So the best choice I seem to have is to build a shared libgit.so.\n> \n> Unfortunately, libgit doesn't have nice symbol names. I dunno how you\n> all would feel about a big patch which renames absoutely every foo()\n> function in libgit to be git_foo() instead (or one that #ifdef's them)...\n> so I'm taking the easy way out, and use versioned symbols. That should\n> prevent symbol name conflicts with other libraries.\n> \n> I've had to redefine usage(), error() and die() to git_*(), because\n> they're just too conflict-ish. \"error\" is even a weak symbol in libc. :-/\n> \n> To summarize, the choices seem to be:\n> - don't do anything => no script language extensions, need to fork off\n>   a git program for absolutely everything. Bah.\n> - build libgit.a with -fpic'd objects => doesn't work on all\n>   architectures.\n> - build libgit.shared.a and use that for building script language\n>   extensions => works now, but may cause name conflicts down the road.\n> - build a \"normal\" libgit.so => ditto on the name conflicts.\n> - build a libgit.so with symbol versions => no name conflicts expected,\n>   but works only with the GNU linker.\n> - rename all library functions and globals => quite a bit of work,\n>   and more typing down the road.\n> - add \"#define foo git_foo\" to all library functions => ugly.\n> \n> Opinions?\n\nRenaming all the library functions and globals is the way to go if the \nlong term view is that Git functionality will be desired in other \nprojects. This is my view.\n\nHowever, it's not clear (to me, anyway) that libgit is structured (other \nthan naming) in a way that's usable for non core-git tools; git-daemon \nwas discussed recently. Some research needs to be done to answer this \nquestion.\n"},{"id":"8700","messageId":"7vmzmcj1eo.fsf@assigned-by-dhcp.cox.net","threadId":"1826","inReplyTo":"pan.2005.09.16.12.37.14.736570@smurf.noris.de","subject":"Re: [PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-16T18:46:55Z","receivedAt":"2005-09-16T18:46:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[David Roundy CC:ed because I was once asked about libgit.a ABI\n stability issues from darcs-git community, and I lost the e-mail\n address of the primary person there who is working on it; but I\n know David is nice enough to arrange the message to be forwarded\n to appropriate places.]\n\nMatthias, I think you are solving a wrong problem.  More\nprecisely, solving problems in a wrong order.\n\nAs things stand, libgit.a should not be taken as \"a library\" but\nmerely as a convenient way to simplify our Makefile [*1*].\nThere are larger problems with what is in the current libgit.a\nviewed as a library if you want to use it to do anything\nremotely interesting:\n\n - Almost all the interesting bits of git-core are in individual\n   programs (rev-list, merge-base, ...).  The functionality from\n   them _could_ be moved into libgit.{a,so}, but many have the\n   built-in assumption that they are run once and the mess they\n   leave behind will be cleaned up by process termination.\n\n - Management of even the most basic data structures used in\n   libgit.a shares the \"run once\" mentality.  I can offhand\n   think of three but I am sure there are more:\n\n   - active_cache: once you are done with the current cache, it\n     is very hard to reinitialize and use it without losing\n     memory [*2*];\n\n   - alternate_odb: GIT_ALTERNATE_OBJECT_DIRECTORIES and\n     info/objects/alternates are looked at only once, and\n     objects are slurped from these directories afterwards; this\n     means you cannot easily switch between repositories (think\n     of doing gitweb in mod-perl, with the libifiled libgit.so).\n\n   - 'struct object' and its descendants: they keep track of\n     which object has been seen, and the marks used by various\n     commands that do the most interesting part of what git does\n     persist; this means that you cannot for example make\n     merge-base libified and run two of them inside a program\n     very easily [*3*] [*4*].\n\n - The naming clash with host programs and other libraries they\n   might use, which you mentioned.\n\nI am not saying the above problems are unsolvable, but I think\nthe naming conflict is the least of them.  You just slurp the\ncurrent git.git into darcs-git, run token replace patch there\nand slurp the results back in, teach the git-core people to use\nthe new names and you are done.  However, without solving the\nsecond one (and to a lesser extent the first one), I do not\nthink you can usefully use the guts of git as a library.  You\ncan read many blobs without spawning git-cat-file for each of\nthem, but that is about how far you could go.  If we were to do\nthe libification properly, those \"run once\" bits should be\nupdated to have \"git_init\" [*5*] to return the handle to a data\nstructure that represents their current state, and be made to\ntake that handle to do their work in their given 'state\nsandbox', and deallocate that state when they are done.\n\nDon't get me wrong.  I would really want to see the guts of git\nlibified and SWIG'ed.  That would help not just your Python\nthing but also StGIT and Fredrik merge (both are Python), as\nwell as gitk (tcl/tk) and gitweb (Perl).  I would not even mind\nseeing all the git barebone Porcelain redone in Python once we\ngo in that direction, ditching the shell scripts we currently\nhave.\n\n\n[Footnote]\n\n*1* We do not have to build and maintain list of object files\neach resulting binary uses in the Makefile and we let the\nlinker find it out for us.\n\n*2* Hopefully this will be fixed when Chuck is done but the work\nand the discussion has just been started and I do not know how the\ntimeframe of this cache abstraction cleanup meshes with 1.0\ntimeframe.\n\n*3* I once wanted to have 'git-rev-parse A...B' to mean\n'git-rev-parse `git-merge-base A B`..B'.  In order to grok\n'git-rev-parse A...B C...D', you should be able to run\nmerge-base twice inside of git-rev-parse.\n\n*4* I think diffcore part is reasonably well libified -- not\nbecause who wrote it was brilliant, but simply because it was\nnecessary for it to be able to get called repeatedly from\n'diff-tree --stdin' form from day one.\n\n*5* Maybe we would want separate git_init_cache,\ngit_init_objects, ... and be able to mix and match them.  Maybe\nnot.  \n"},{"id":"8716","messageId":"432B2172.8090803@citi.umich.edu","threadId":"1826","inReplyTo":"7vmzmcj1eo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","fromName":"Chuck Lever","fromEmail":"cel@citi.umich.edu","sentAt":"2005-09-16T19:48:02Z","receivedAt":"2005-09-16T19:48:02Z","isPatch":true,"sender":{"key":"cel@citi.umich.edu","avatar":null},"body":"Junio C Hamano wrote:\n>  - Management of even the most basic data structures used in\n>    libgit.a shares the \"run once\" mentality.  I can offhand\n>    think of three but I am sure there are more:\n> \n>    - active_cache: once you are done with the current cache, it\n>      is very hard to reinitialize and use it without losing\n>      memory [*2*];\n\n> *2* Hopefully this will be fixed when Chuck is done but the work\n> and the discussion has just been started and I do not know how the\n> timeframe of this cache abstraction cleanup meshes with 1.0\n> timeframe.\n\nwell, i kept the \"run-once\" mentality.  if that's something you'd like \nto go away, i can do that too, at some later point.\n\n\nbegin:vcard\nfn:Chuck Lever\nn:Lever;Charles\norg:Network Appliance, Incorporated;Linux NFS Client Development\nadr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA\nemail;internet:cel@citi.umich.edu\ntitle:Member of Technical Staff\ntel;work:+1 734 763 4415\ntel;fax:+1 734 763 4434\ntel;home:+1 734 668 1089\nx-mozilla-html:FALSE\nurl:http://www.monkey.org/~cel/\nversion:2.1\nend:vcard\n\n"},{"id":"8720","messageId":"7vll1whj5z.fsf@assigned-by-dhcp.cox.net","threadId":"1826","inReplyTo":"432B2172.8090803@citi.umich.edu","subject":"Re: [PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-16T20:06:16Z","receivedAt":"2005-09-16T20:06:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chuck Lever <cel@citi.umich.edu> writes:\n\n> well, i kept the \"run-once\" mentality.  if that's something you'd like \n> to go away, i can do that too, at some later point.\n\nI did not mean to pressure you or suggest doing it in this\nround.\n\nI should have said \"this will become easier to fix when Chuck is\ndone...\".\n"},{"id":"8724","messageId":"432B2864.5010901@citi.umich.edu","threadId":"1826","inReplyTo":"7vll1whj5z.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","fromName":"Chuck Lever","fromEmail":"cel@citi.umich.edu","sentAt":"2005-09-16T20:17:40Z","receivedAt":"2005-09-16T20:17:40Z","isPatch":true,"sender":{"key":"cel@citi.umich.edu","avatar":null},"body":"Junio C Hamano wrote:\n> Chuck Lever <cel@citi.umich.edu> writes:\n> \n> \n>>well, i kept the \"run-once\" mentality.  if that's something you'd like \n>>to go away, i can do that too, at some later point.\n> \n> \n> I did not mean to pressure you or suggest doing it in this\n> round.\n> \n> I should have said \"this will become easier to fix when Chuck is\n> done...\".\n> \n\nno pressure.  i can see a pretty easy way to add it in, though.\n\n\nbegin:vcard\nfn:Chuck Lever\nn:Lever;Charles\norg:Network Appliance, Incorporated;Linux NFS Client Development\nadr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA\nemail;internet:cel@citi.umich.edu\ntitle:Member of Technical Staff\ntel;work:+1 734 763 4415\ntel;fax:+1 734 763 4434\ntel;home:+1 734 668 1089\nx-mozilla-html:FALSE\nurl:http://www.monkey.org/~cel/\nversion:2.1\nend:vcard\n\n"},{"id":"8728","messageId":"20050916211040.GU7646@kiste.smurf.noris.de","threadId":"1826","inReplyTo":"7vmzmcj1eo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] Build a shared / renamed / \"stable\" version of the library?","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-09-16T21:10:41Z","receivedAt":"2005-09-16T21:10:41Z","isPatch":true,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nJunio C Hamano:\n> Matthias, I think you are solving a wrong problem.  More\n> precisely, solving problems in a wrong order.\n> \nI've since looked a bit more closely at the \"library\" code, and ...\nwell, you're obviously right. :-/\n\n> can read many blobs without spawning git-cat-file for each of\n> them, but that is about how far you could go.\n\nPrecisely that was the first application I needed the library for. ;-)\n\n> Don't get me wrong.  I would really want to see the guts of git\n> libified and SWIG'ed.  That would help not just your Python\n> thing but also StGIT and Fredrik merge (both are Python), as\n> well as gitk (tcl/tk) and gitweb (Perl).  I would not even mind\n> seeing all the git barebone Porcelain redone in Python once we\n> go in that direction, ditching the shell scripts we currently\n> have.\n> \nYou and me both...\n\n> *5* Maybe we would want separate git_init_cache,\n> git_init_objects, ... and be able to mix and match them.  Maybe\n> not.  \n> \nMakes sense. First steps would probably be to invent \"struct\ngit_repository\" and \"struct git_cache\" data structures. Fun. ;-)\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nINSIDE, I have the same personality disorder as LUCY RICARDO!!\n\t\t-- Zippy the Pinhead\n"}]}