As Gordon mentioned, I did indeed mean the other wrappers for the C++ client rather than the python etc clients, and that adding to the output of release.sh is differnet than just adding support to a component build to produce a new artifact. It is however reasonable to note that we are actually releasing duplicate copies of the source for the python client.
I'm not actually suggesting it is wrong to add such an artifact for the Perl bits, just noting that it was disussed before that we consider moving away from publishing multiple artifacts for the same source and so should possibly be discussed before we go doing it again for some more bits but not others and becoming even more inconsistent than we already are now. Robbie On 13 July 2012 15:45, Darryl L. Pierce <[email protected]> wrote: > 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/ > >
