On Tue, Jun 19, 2012 at 12:07:27PM -0500, Steve Huston wrote: > Collecting the bindings seems like a good idea, but how do you envision > building the bindings? You mentioned breaking the cmake dependencies. Are > you planning to break the dependency on the cpp directory's > CMakeLists.txt, or on cmake all together? What triggers the need to build > the bindings when the cpp dirs change?
We wouldn't break away from cmake altogether. By that I meant that, if
we started versioning the SWIG code generated currently, then we would
not have a direct dependency from, say, the Perl bindings onto the C++
code. We could build it completely separately from C++.
And like I mentioned in my email to Andrew, I'm not sure I like that
idea. I would rather have the C++ code be its own single cmake project.
Then have either the individual language bindings each be single
projects that then depend (via cmake) on the C++ projects.
So that way I could do:
cmake ../qpid/cpp # to build the C++ code
cmake ../qpid/bindings/qpid/perl # to build the Perl bindings, which
# would in turn build C++ as needed
cmake ../qpid/bindings/qpid/ruby # ibid, for Ruby
cmake ../qpid/bindings # build C++ then all language bindings
cmake ../qpid # build the world
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
pgp3f08OSVNPC.pgp
Description: PGP signature
