Build rabbitmq-c without rabbitmq-codegen submodule #98

merged 3 commits into from Jan 16, 2013


None yet
3 participants

alanxz commented Jan 16, 2013

This is a partial fix for #96.

This patch allows building rabbitmq-c without having to do a git submodule init/update, which will users to download source archives from github that can be built out-of-the-box.

This also relieves the necessity to have python available.

It is still possible to regenerate amqp_framing.c/.h by passing REGENERATE_AMQP_FRAMING=ON to cmake or --enable-regen-amqp-framing to ./configure.

alanxz added some commits Jan 16, 2013

Use https for codegen submodule URI protocol
https is more likely to be allowed through corporate firewalls than the
git protocol
Build without codegen
Changes to support building rabbitmq-c without having run the python
code generator, or do a git submodule init/update.

This is to facilitate creating links to downloadable source archives
from github

@alanxz alanxz merged commit d008bb0 into master Jan 16, 2013

1 check passed

default The Travis build passed

@alanxz alanxz deleted the issue96_without_codegen branch Jan 16, 2013

Hi thanks for new version! I was writing ebuild for latest changes and found that use --enable-regen-amqp-framing and --disable-dependency-tracking fail make due to missed librabbitmq/gen/amqp_framing.h. I know that generating framings is for developers only but if it not too difficult can you fix that and update tag v0.3.0?


alanxz commented Jan 18, 2013

As a general rule, once I push something to the master branch (this includes tags) I don't change it. So I will not change that tag. When it makes sense I will add another tag like v0.3.1

I see how this is failing: the code generator tries to write to the librabbitmq/gen directory which does not exist, when the dependency tracker is turned on, this directory gets automatically created. I'll see what I can do to fix this.

Two questions for you:

  • Why are you using the autotools build instead of the CMake based build? I would really like to move away from autotools in the near future (maintaining two parallel build systems is a headache and error-prone).
  • Why are you adding --disable-dependency-tracking to the configure flags? (This some gentoo ebuild best-practice or something?)

Finally, I would encourage you if you're writing an ebuild (or any other packaging method) that gets distributed widely, to not to use developer features. It creates a potential situation where I get asked support questions about developer features that may not work, or worse it gives a false impression that the library is broken.


alanxz commented Jan 18, 2013

Pushed 24ffaf8 which should fix the problems with --disable-dependency-tracking you're seeing.

Thanks. Ebuild system since EAPI 4 add --disable-dependency-tracking if it presents in --help output and there is no known easy and correct way to change that without patching config. I'm not very happy on such behavior, but yeah, looks like it's a best practice. I was adding developer functionality only to live ebuild which regular user should not actually install while it's masked and even then live ebuilds highly unstable per se.

I will rewrite ebuilds to use CMake instead autotools, just didn't know that you have planes to drop autotools.

@pinepain I've update my ebuild to use cmake, please see the 0.3.0 version available here:

@alanxz after much turmoil trying to get the documentation to build correctly I ended up with a patch for you:

Can you pull that patch in for your next release?

@alanxz I'd also make the suggestion to stick with numbers only in your tags. It makes the folders weird. ie the tag should be simply "0.3.0" etc. Then the generated zip file(s) and folders follow more standard conventions.

I also vote up for just MAJOR.MINOR.RELEASE[-alpha/beta/rc1, etc] tag naming


alanxz commented Jan 19, 2013

@travisghansen what kind of errors were you getting with the XmlTo finder?

@alanxz see below:
thansen@15z ~/Downloads/rabbitmq-c-rabbitmq-c-v0.3.0/build $ cmake -DBUILD_TOOLS=ON -DBUILD_TOOLS_DOCS=ON ..
CMake Warning at tools/CMakeLists.txt:70 (message):
xmlto not found, will not build tools documentation

I based my work off of other examples I found (specifically around XmlTo_FOUND examples). I'm by no means a build system guy so if it needs improvement feel free.


alanxz commented Jan 19, 2013

What version of CMake are you using?

same here, cmake version 2.8.9

@alanxz I'm on


alanxz commented Jan 20, 2013

Ok, I think I have a fix for the issue you're running into. Could you try building the branch off of #100 and see if that fixes your issue?

@alanxz looks good. If I have further issue when an actual tag comes out I'll let you know. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment