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?
-- Steve Huston, Riverace Corporation Total Lifecycle Support for Your Networked Applications http://www.riverace.com > -----Original Message----- > From: Darryl L. Pierce [mailto:[email protected]] > Sent: Tuesday, June 19, 2012 12:00 PM > To: [email protected] > Subject: Relocating the language bindings... > > Last week Ted and I talked about moving the language bindings out from > under the cpp directory tree. So, in the end, we'd have something like: > > qpid/ > cpp/ > bindings/ > qpid/ > perl/ > python/ > ruby/ > > (unless someone has a better suggestion) > > Also, during a discussion today with Justin we talked about versioning the > generated language bindings from SWIG in those bindings directory. I have > mixed feelings on this, but also wanted to solicit opinions on doing this. > > The big benefit to this would be breaking the Cmake dependencies between > the bindings and the cpp build tree. We could build them independently, > which is a Good Thing (tm). > > The downside, though, is when the public APIs change and the SWIG > bindings aren't updated. Though we'd find out pretty quickly that they were > out of date. > > Opinions? Thoughts? > > -- > 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/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
