Closed GoogleCodeExporter closed 9 years ago
First I have to ask, why create a new issue for something there's already an
open issue for?
Then your questions:
o Protobuf-C:
Originally there were patches added to this part. It also used to be impossible
to build it in a cross-compiling setting. See
http://code.google.com/p/protobuf-c/issues/detail?id=34&can=1. Now this is
fixed, but I'm worried about compatibility between releases which seems to
change, meaning that the Mumble.proto files have to be regenerated depending on
the version of protobuf-c. It's just a possible source of problems which I have
workaround this way.
o Merge src - topdir:
I don't really know what you mean by 'standard', but this is a pretty common
and in my opinion convenient way of organizing the source tree.
o SVN:
Googlecode provides svn and mercurial. Not git. I do mind using git. There is
one committer in this project, which is me. For a larger project with many
committers I would certainly consider git. Where did you find the blatantly
false information that svn is 'outdated'?
Original comment by fatbob.s...@gmail.com
on 23 Mar 2011 at 1:34
When I wrote this issue I though that it was way more general than just a
./configure-related issue. Anyway, that's true that some parts are common so
you can merge this one into the other.
-Protobuf-C:
If you don't mind I'll have a look into using it as an external library instead
of a part of umurmur project. This will change how autoconf is handling it.
-Merge src - topdir
Nevermind, this is the good way to do it but I'll put the ./configure script
and Makefile and so on in topdir.
No need to cd in src before starting to compile this way.
-SVN:
I've seen some Googlecode projects with their source on GitHub and their
issues/wiki on Googlecode (for example : Sick-Beard)
GitHub makes easier the way to work on projects that you don't own (like
umurmur in my case). For example, I forked syno-packager from sarav
(https://github.com/sarav/syno-packager), made some commits on my own, pushed
them on GitHub so everyone can access it and submited a pull-request to sarav.
He can now merge my changes whenever he wants and I can still work on my side,
making commits and so on.
The key idea here is that I can make multiple small commits instead of a huge
incomprehensible patch.
Anyway, I can live with that, your choice.
About the "outdated" part, what I mean is that svn is great but lacks a bit a
flexibility compared to newest tools (git/mercurial) as it requires a server.
Original comment by DiaoulAel
on 23 Mar 2011 at 2:49
It would have been easier to respond to your questions and suggestions in a
constructive way if the motives were stated too from start. Now that I know,
I'll start thinking about moving to git. I'm more used to svn but it's always
good to learn something new :)
Please do look into moving out protobuf-C, I don't mind. The configure script
should probably make sure that it's version 0.14, otherwise Mumble.pb-c.[ch]
might need to be regenerated.
Original comment by fatbob.s...@gmail.com
on 23 Mar 2011 at 3:35
Unfortunatly, there is no way I can check if the version is 0.14 as protobuf-c
doesn't come with a version.h header...
Let's just write it down somewhere in the wiki until a version.h is implemented
for protobuf-c
Original comment by DiaoulAel
on 24 Mar 2011 at 9:42
Original comment by fatbob.s...@gmail.com
on 16 Apr 2011 at 8:19
Original issue reported on code.google.com by
DiaoulAel
on 23 Mar 2011 at 9:08