On Fri, Jul 13, 2012 at 03:26:57PM +0100, Gordon Sim wrote: > >Right now the other language bindings do, in fact, have separate source > >releases: the python-qpid tarball > > I think by 'other bindings' Robbie means the clients that wrap the > c++ client, which are located under cpp/bindings. The python-qpid > tarball is not one of these, it is a pure python client based on the > code under the python top level directory.
Okay, I understand better his point. > >and the Ruby gemfile (though the > >latter isn't officially created as of yet, it is still a distinct > >release artifact from the monolithic C++ codebase). > > Again, I think the observation behind the question is that the > release script does not support generating the source for the ruby > client nor has it been part of the release. > > Modifying the makefiles/build procedure for one of the bindings > within an existing release artefact is a different thing from adding > a new release artefact. 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. > The Makefile.PL in your patch seems to add relative paths that are > not included in the source itself. What is the intended usage here? > There is also a path to /usr/lib64 which seems potentially fragile? Hrm, that's the wrong Makefile.PL committed there. While testing the patch, it looks like it went through and generated a Makefile.PL from the old Makefile.PL.in, which was then committed over the Makefile.PL I wish to include. > The release script requires compiling the c++ client as part of > generating the perl 'sources'. Is that necessary? Does the > generation of sources require more than the public header files? > What impact if any does the version of swig, gcc, perl etc on the > release machine have on the final artefact? The portion to create the Perl sources I copied from the C++ section. As you say, SWIG doesn't require any more than the headers so I can dial that part back. > Am I correct in inferring that the swig input files themselves are > not considered part of the source, only the .cpp and .pm files? If > so is that really what we want? The point of making sources > available is so that the user can patch them themselves. You would > generally rather patch the swig files than any generated code, no? For what we're doing with the perl-qpid package, only the generated cpp and pm files are of import. Yes, if there's a change to what swig would generate then we could update the package by generating a patch to apply to the generated sources or rebase on the updated tarball. -- 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/
pgpahtTp3VY2p.pgp
Description: PGP signature
