On Wed, Jun 20, 2012 at 6:50 PM, Andrew Stitcher <[email protected]> wrote: > On Wed, 2012-06-20 at 15:34 -0400, Darryl L. Pierce wrote: >> On Wed, Jun 20, 2012 at 03:24:52PM -0400, Andrew Stitcher wrote: >> > On Tue, 2012-06-19 at 16:05 -0400, Darryl L. Pierce wrote: >> > > On Tue, Jun 19, 2012 at 02:11:51PM -0400, Andrew Stitcher wrote: >> > > > > 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). >> > > > >> > > > I don't think you are really breaking any dependencies by moving code >> > > > around are you? The bindings will still depend on the c++ code where >> > > > ever it lives in the tree. >> > > >> > > What I was thinking was that, by moving the bindings out and then >> > > versioning the SWIG wrapper code we could build the individual language >> > > bindings separately rather than having to build all of Qpid to get them. >> > > I'm still not totally comfortable with the idea of versioning those >> > > wrappers. >> > >> > Could you explain what you mean by "versioning" in this context? >> >> Generating a copy of the SWIG wrapper for that language and then commit >> it in git. > > I don't think committing generated code to the repository is a good idea > (but I could be convinced). Why do want to do this?
For the Java binding, the generated code (compiled into a jar file) is checked into the java lib dir. I see no way around it, unless you make the java build (for the cpp based api implementation) conditional on the cpp build, which is not going to fly. Rajith > Andrew > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
