MinGW64 bit support.

[onepremise]

I'm not sure if you noticed, but I have a working build of protobuf-c for 64bit MinGW:

https://github.com/onepremise/protobuf-c

I had created this project before you guys moved over to github. I'll have to fork and rebase my changes. I would like to eventually recontribute my changes back to the parent project.

You can actually download the build as part of a larger distribution for 64bit MinGW:

https://vanguard.houghtonassociates.com/browse/MINGLE-MINGLE64-140/artifact

I'm opening this ticket for tracking, bringing my changes back up to date, and feedback.

[edmonds]

hi, jason:

no, sorry, we hadn't noticed. part of the point of moving protobuf-c to github was to make it unnecessary for people to do their own git-svn conversions :-)

looking at your repo, it looks like your changes only touch the RPC code, and our version of the github repo has been rearranged so that all of the RPC code is clearly isolated to the top-level protobuf-c-rpc/ directory. and i think there might already be a commit changing AF_LOCAL to AF_UNIX to fix the build on another platform (probably solaris).

i'm curious -- are you actually using the protobuf-c RPC code for anything, or is your interest in the RPC code limited to keeping your build working? i'm pondering whether the protobuf-c-rpc code should be split out into another repository with its own build system so that people who are just interested in the protobuf encoding/decoding library and code generator don't have to carry the burden of building the RPC system as well.

[onepremise]

i'm curious -- are you actually using the protobuf-c RPC code for anything, or is your interest in the RPC code limited to keeping your build working?

Not really. We use protobuf-c for OSM2PGSQL, another tool I've ported to 64 bit MinGW, which requires your library for encoding/decoding pbf files. I don't think OSM2PGSQL uses the RPC code. I think I had a few issues with the RPC unit tests passing and it would be pretty apparent if OSM2PGSQL failed as a result of RPC code.

[lipnitsk]

@edmonds, are you planning to keep @protobuf-c mainline strictly as an autotools project and have people fork it if they want to add CMake/SCons/etc? Another option might be to have a CMake branch in the mainline repo, but somebody would have to maintain that. Is autotools a real pain to get working on Windows?

[edmonds]

@lipnitsk yeah, i don't see much reason to have multiple build systems. i don't know how difficult or not autotools projects are to build on windows. presumably cygwin/mingw is much more GNU compatible than VS, though.

[edmonds]

looking at onepremise/protobuf-c@6524aba this only affects the rpc code, which was split out into a separate protobuf-c-rpc project. this issue should be reopened at https://github.com/protobuf-c/protobuf-c-rpc/issues. (i don't know if it's possible to move an issue between repositories.)