On 07/13/2012 03:45 PM, Darryl L. Pierce 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.
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 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.
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.
I think that is debatable. Again, the point of including the sources is
to give users freedom and flexibility to patch and rebuilt themselves.
Not including the sources required to regenerate code limits that in my
view.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
