On Fri, Jul 13, 2012 at 04:54:10PM +0100, Gordon Sim wrote: > >So what would be a better path to take then? My goal here is to have a > >smaller tarball that would be the upstream source for the perl-qpid > >package in this case. > > In the short term, perhaps a make target in the cpp project to > create the perl tarball would be sufficient? Or even just a specific > script to include with the binding itself in the cpp source tarball?
I do have a separate build target that's a part of the Cmake system that produces the tarball called "perl_sources". It's embedded in this patch set. > I do think the bindings could probably be separated from the cpp > build (but I don't know that much about them). That may well be a > beneficial thing to do and that may then solve the issue. I recall a > thread on this recently, so trying to bring that to a conclusion for > the next release might be a good path. I have a separate patch out there that achieves this goal; i.e., it excludes the language bindings from the build by default in Cmake. [1] That way anybody working on just C++ can avoid having to build all of that, while someone like me working on the bindings calls the appropriate language target and it compiles the C++ code dependencies. [1] https://issues.apache.org/jira/browse/QPID-4083 -- 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/
pgpIskPkPAU88.pgp
Description: PGP signature
