On 07/13/2012 02:09 PM, Darryl L. Pierce wrote:
On Fri, Jul 13, 2012 at 12:32:13AM +0100, Robbie Gemmell wrote:
We have previously discussed only having a single source release tar
instead of duplicating the source across multiple archives, this seems to
go further against that grain. Also, what makes the perl bindings get their
own source tar release but not other bindings?
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.
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.
Being able to generate such an archive and it actually being part of the
release artifacts seem like separate issues to an extent.
In taking these separate packages through review on Fedora, the first
thing reviewers have asked for is "where can I find the source for this
package?" And pointing them to a tarball that is 99% unnecessary and
unused by the package seems the wrong answer.
In this case we're not really duplicating anything: the perl tarball
only those few files needed to do a Perl language bindings release and
nothing else. Files that no longer need to be included in the C++ source
release.
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?
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?
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
