[rabbitmq-discuss] rabbitmq-c versus MSYS

Sat Aug 29 13:41:27 BST 2009

Michael Nacos wrote:
> ...
> make[2]: *** No rule to make target `codegen/amqp-0.8.json', needed by 
> `amqp_framing.h'.  Stop.
> make[2]: Leaving directory `/c/Projects/rabbitmq-c/librabbitmq'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/c/Projects/rabbitmq-c'
> make: *** [all] Error 2
>
> then again, there is no python support in MSYS. IYO, what would be the 
> best way forward?

Have you tried installing ActiveState Python?

In the old XORP world order, we shipped a set of Windows binaries for 
routing processes built under MSYS. The RPC stubs in the tree were 
generated with Python, and we used to check them in directly.

There can be some subtle path issues with MSYS, because whilst it 
supports a UNIX-like development environment, all binaries are in fact 
invoked via the usual Win32 command line subsystem mechanisms.

In practice this usually isn't an issue, providing the tool(s) are in 
your PATH, and/or scripts/builders invoked directly by the MinGW port of 
GNU Make use the #!/usr/bin/env construct.

We found it *was* an issue where child processes were expected to be run 
under an MSYS bash shell, as the MSYS runtime tries to deal with 
situations where DOS-style, NT/UNC-style and UNIX-style paths are mixed. 
As you probably already know, GNU Make will try to use bash wherever it can.

You might want to have a look at the legacy build notes for XORP:

http://xorp.svn.sourceforge.net/viewvc/xorp/trunk/xorp/BUILD_NOTES?revision=11305&view=markup

We have since moved away from GNU Autotools to SCons, which is 
significantly better in a number of ways; tedious regeneration of the 
build glue is not needed every time an incremental change is made.

thanks,
BMS