tst2005googlecode / umurmur

Automatically exported from code.google.com/p/umurmur
1 stars 0 forks source link

Refactoring : Externalize protobuf, etc. #23

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

I'm creating a patch so umurmur can use autotools.
Here some questions to understand your choices :

I think it would be better to to use protobuf at compilation time like polarssl 
instead of including it in umurmur's source code.
Did you made any modifications on this lib ?

Why not merge src directory with topdir in order to be more standard ?

Why do you still use the outdated subversion tool ? Would you mind using git ? 
Git is a great alternative with much more capabilities, take a look at github.

Thanks

Original issue reported on code.google.com by DiaoulAel on 23 Mar 2011 at 9:08

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by fatbob.s...@gmail.com on 16 Apr 2011 at 8:19