qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Pierce" <dpie...@redhat.com>
Subject Re: 0.18 inclusion request - Perl upstream tarball changes
Date Fri, 13 Jul 2012 14:45:37 GMT
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.

View raw message