You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Darryl L. Pierce" <dp...@redhat.com> on 2012/07/12 21:29:52 UTC
0.18 inclusion request - Perl upstream tarball changes
Please consider the following patch for inclusion in 0.18:
https://issues.apache.org/jira/browse/QPID-4134
This patch set provides a new target for release.sh to bundle together
the Perl sources. It also includes changes to the CMakeLists.txt and two
new files in the bindings/qpid/perl directory.
--
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/
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by Robbie Gemmell <ro...@gmail.com>.
I can't really comment on the specific changes as I have no experience with
those bits, but the simplified focus seems reasonable to me.
Robbie
On 18 July 2012 14:28, Darryl L. Pierce <dp...@redhat.com> wrote:
> On Fri, Jul 13, 2012 at 01:56:42PM -0400, Darryl L. Pierce wrote:
> > On Thu, Jul 12, 2012 at 03:29:52PM -0400, Darryl L. Pierce wrote:
> > > Please consider the following patch for inclusion in 0.18:
> > >
> > > https://issues.apache.org/jira/browse/QPID-4134
> > >
> > > This patch set provides a new target for release.sh to bundle together
> > > the Perl sources. It also includes changes to the CMakeLists.txt and
> two
> > > new files in the bindings/qpid/perl directory.
> >
> > Based on feedback, I dialed this back to something a bit simpler.
> >
> > Now, instead, this patch provides just the Cmake target for producing
> > the Perl sources for perl-qpid. It no longer adds a target to the
> > release.sh file, and does not touch the autotools system at all.
> >
> > Still would like this to go into 0.18.
>
> Any opinions on including this?
>
> --
> 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/
>
>
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Jul 13, 2012 at 01:56:42PM -0400, Darryl L. Pierce wrote:
> On Thu, Jul 12, 2012 at 03:29:52PM -0400, Darryl L. Pierce wrote:
> > Please consider the following patch for inclusion in 0.18:
> >
> > https://issues.apache.org/jira/browse/QPID-4134
> >
> > This patch set provides a new target for release.sh to bundle together
> > the Perl sources. It also includes changes to the CMakeLists.txt and two
> > new files in the bindings/qpid/perl directory.
>
> Based on feedback, I dialed this back to something a bit simpler.
>
> Now, instead, this patch provides just the Cmake target for producing
> the Perl sources for perl-qpid. It no longer adds a target to the
> release.sh file, and does not touch the autotools system at all.
>
> Still would like this to go into 0.18.
Any opinions on including this?
--
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/
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Jul 12, 2012 at 03:29:52PM -0400, Darryl L. Pierce wrote:
> Please consider the following patch for inclusion in 0.18:
>
> https://issues.apache.org/jira/browse/QPID-4134
>
> This patch set provides a new target for release.sh to bundle together
> the Perl sources. It also includes changes to the CMakeLists.txt and two
> new files in the bindings/qpid/perl directory.
Based on feedback, I dialed this back to something a bit simpler.
Now, instead, this patch provides just the Cmake target for producing
the Perl sources for perl-qpid. It no longer adds a target to the
release.sh file, and does not touch the autotools system at all.
Still would like this to go into 0.18.
--
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/
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Jul 13, 2012 at 04:45:46PM +0100, Robbie Gemmell wrote:
> 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.
That's fine. I'm open to suggestions as to what others think is an
appropriate way to go. My goal is to have only what's absolutely
necessary in the upstream for the Perl bindings so that it can be a
top-level package of its own.
--
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/
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <dp...@redhat.com> 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/
>
>
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Jul 13, 2012 at 04:54:10PM +0100, Gordon Sim wrote:
> >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 have a separate build target that's a part of the Cmake system that
produces the tarball called "perl_sources". It's embedded in this patch
set.
> 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.
I have a separate patch out there that achieves this goal; i.e., it
excludes the language bindings from the build by default in Cmake. [1]
That way anybody working on just C++ can avoid having to build all of
that, while someone like me working on the bindings calls the
appropriate language target and it compiles the C++ code dependencies.
[1] https://issues.apache.org/jira/browse/QPID-4083
--
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/
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by Gordon Sim <gs...@redhat.com>.
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
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/
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by Gordon Sim <gs...@redhat.com>.
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
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 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).
> 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.
--
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/
Re: 0.18 inclusion request - Perl upstream tarball changes
Posted by Robbie Gemmell <ro...@gmail.com>.
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?
Being able to generate such an archive and it actually being part of the
release artifacts seem like separate issues to an extent.
Robbie
On 12 July 2012 20:29, Darryl L. Pierce <dp...@redhat.com> wrote:
> Please consider the following patch for inclusion in 0.18:
>
> https://issues.apache.org/jira/browse/QPID-4134
>
> This patch set provides a new target for release.sh to bundle together
> the Perl sources. It also includes changes to the CMakeLists.txt and two
> new files in the bindings/qpid/perl directory.
>
> --
> 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/
>
>