On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote: > Pierre Habouzit <madcoder@xxxxxxxxxx> wrote: > How about this? > > http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS looks like a good start. > > Second, if we want this to be a successful stuff, we all agree we must > > let git be able to use it medium term. That means that when git-core is > > experimenting with new interfaces, it will probably need to hook into > > some more internal aspects of the library. This is a problem to solve > > elegantly, linking git against a static library won't please a lot of > > vendors and linux distributions, and exporting "private" symbols is a > > sure way to see them being abused. > > Private symbols are a problem. On some systems we can use link > editing to strip them out of the .so, but that isn't always going to > work everywhere. I've outlined the idea of using double underscore > to name private functions, and we can link-edit out '*__*' if the > platform's linker supports it (e.g. GNU ld). Well, I propose the following: we set-up on GNU-ld + gcc enabled systems all what is needed to use symbol visibility, which isn't that intrusive, and also rather easy given your GIT_EXPORT macro definition. This way, people who care about portability across all libgit2 supported platforms will have to align on the lowest common denominator, which will not have any kind of private stuff available, so we're safe. And GCC/GNU-ld enabled platforms cover most of the popular platforms (namely linux and *BSD, I'm not sure about Macos dynlibs). Even win32 has kind of what you need to do visibility I think. IOW prehistoric systems will be have to cope with that because of Linux (yeah, this is kind of deliciously backwards ;p). No, my worry was rather wrt git core itself, I really think we _must_ make it link against libgit2 if we want libgit2 to stay current, but git core will _very likely_ need the private stuff, and it _will_ be a problem. I mean we cannot seriously so-name a library and show its guts at the same time, and I'm unsure how to fix that problem. _that_ was my actual question. > > Last but not least, I believe parts of git-core are currently easy to > > just take. For example, any code *I* wrote, I hereby give permission to > > relicense it in any of the following licenses: BSD-like, MIT-like, > > WTFPL. > > Yea. We could try to do that. I don't know how far it will get us, > but if we have to "steal" code we can rip a good part from JGit. > Its BSD-like, but has that "icky Java smell" to it. :-) > > Before worrying about where we get implementation bits from I'm > more interested in trying to get a consistent view of what our > namespace looks like, and what our calling conventions are, so we > have some sort of benchmark to measure APIs against as we add them > to the implementation. I'd say we should do both at the same time. Asking people if they would agree to relicense code can be done in parallel. We could extract a list of source files that we may need (my extraction included stuff that is very unlikely to be useful like test-*.c that aren't useful, and some that are already BSD I think), and see who it yields. It should be possible to do a matrix source-file x people and see on a per-file basis what they think. If someone gives me the list of files we should consider (I'm not sure about a good list right now) I could do the matrix at some fixed sha1 from git.git using git blame -C -M -M -w, and ask people see where it leads us ? -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpmrDXq6hLT0.pgp
Description: PGP signature
