Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1029732 > unrolled thread

Bug#972785: zeromq3: Include cmake files for cppzmq

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#972785: zeromq3: Include cmake files for cppzmq Gordon Ball <gordon@chronitis.net> - 2020-10-23 17:00 +0200
    Bug#972785: zeromq3: Include cmake files for cppzmq László Böszörményi (GCS) <gcs@debian.org> - 2020-10-25 17:20 +0100
      Bug#972785: zeromq3: Include cmake files for cppzmq Gordon Ball <gordon@chronitis.net> - 2020-10-26 10:10 +0100
      Bug#972785: zeromq3: Include cmake files for cppzmq Luca Boccassi <bluca@debian.org> - 2020-10-26 11:00 +0100
        Bug#972785: zeromq3: Include cmake files for cppzmq Gordon Ball <gordon@chronitis.net> - 2020-10-26 12:50 +0100
          Bug#972785: zeromq3: Include cmake files for cppzmq Luca Boccassi <bluca@debian.org> - 2020-10-26 13:00 +0100
            Bug#972785: zeromq3: Include cmake files for cppzmq Gordon Ball <gordon@chronitis.net> - 2020-10-26 13:40 +0100
              Bug#972785: zeromq3: Include cmake files for cppzmq Luca Boccassi <bluca@debian.org> - 2020-10-26 14:10 +0100
                Bug#972785: zeromq3: Include cmake files for cppzmq Gordon Ball <gordon@chronitis.net> - 2020-10-26 20:00 +0100

#1029732 — Bug#972785: zeromq3: Include cmake files for cppzmq

[Multipart message — attachments visible in raw view] — view raw

Source: zeromq3
Severity: normal
Tags: patch

src:zeromq3 and libzmq3-dev currently embed headers from the separate
cppzmq repository. However, the associated cmake files are not included,
which means when trying to build downstream projects which use cppzmq
and cmake, it's necessary to hack the buildsystem or embed the cmake
files from cppzmq.

I've included a patch (against 4.3.3-2) which adds these files to the
source package and libzmq3-dev. Specifically:

 * move the existing cppzmq files (zmq.hpp, zmq_addon.hpp) to
   debian/cppzmq/ and add the cmake files from cppzmq 4.6.0
 * add Provides: cppzmq-dev to libzmq3-dev, which would hopefully make
   it easier to split the packages in future
 * build-depend on cmake, and add an override after dh_auto_install to
   process and install the cmake.in files from cppzmq 

I appreciate this is a larger change than #951135. Other options would be to

* continue to bundle cppzmq in a common source package, but use
  multiple upstream tarballs so cppzmq is a more obvious component and
  the embedded files can be more readily updated together.
* split cppzmq into a separate source package. Some downstream
  dependencies would need to be fixed. Codesearch suggests gnuradio,
  libopenshot, thrift, tango, ignition-transport, horizon-eda

Gordon

[toc] | [next] | [standalone]

#1029931

On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> src:zeromq3 and libzmq3-dev currently embed headers from the separate
> cppzmq repository. However, the associated cmake files are not included,
> which means when trying to build downstream projects which use cppzmq
> and cmake, it's necessary to hack the buildsystem or embed the cmake
> files from cppzmq.
 These are different projects and should be packaged differently. As
czmq is packaged by Luca, I think cppzmq should be packaged by him as
well. But let's hear what he says.

Regards,
Laszlo/GCS

[toc] | [prev] | [next] | [standalone]

#1030014

On Sun, Oct 25, 2020 at 05:13:52PM +0100, László Böszörményi (GCS) wrote:
> On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > cppzmq repository. However, the associated cmake files are not included,
> > which means when trying to build downstream projects which use cppzmq
> > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > files from cppzmq.
>  These are different projects and should be packaged differently. As
> czmq is packaged by Luca, I think cppzmq should be packaged by him as
> well. But let's hear what he says.
> 

Yes, this seems reasonable. I'm quite willing to see the patch I
prepared as a bit of a nasty hack.

I prepared standalone packaging for cppzmq a while ago before I realised
that it collided with headers already in libzmq3-dev. The packaging can
be found here: https://salsa.debian.org/chronitis/cppzmq - it's pretty
trivial since it's header only. The package should be more or less ready
to upload if wanted (but probably should be moved out of my salsa namespace).

However, the maintainer point is a good one. I'm coming at ZMQ in
general as a downstream user and I'm not a domain expert; it would be very
good if the packaging was maintained or co-maintained by someone who
knows the details of ZMQ a bit better.

> Regards,
> Laszlo/GCS

[toc] | [prev] | [next] | [standalone]

#1030021

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > cppzmq repository. However, the associated cmake files are not included,
> > which means when trying to build downstream projects which use cppzmq
> > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > files from cppzmq.
>  These are different projects and should be packaged differently. As
> czmq is packaged by Luca, I think cppzmq should be packaged by him as
> well. But let's hear what he says.
> 
> Regards,
> Laszlo/GCS

Hi,

Given it's just a header, I don't think it's necessary to do anything
complicated - there's nothing to build and there's no dependencies to
track. No point in having separate packages or cmake files or whatnot -
#include is all a user needs.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1030044

On Mon, Oct 26, 2020 at 09:48:52AM +0000, Luca Boccassi wrote:
> On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> > > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > > cppzmq repository. However, the associated cmake files are not included,
> > > which means when trying to build downstream projects which use cppzmq
> > > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > > files from cppzmq.
> >  These are different projects and should be packaged differently. As
> > czmq is packaged by Luca, I think cppzmq should be packaged by him as
> > well. But let's hear what he says.
> > 
> > Regards,
> > Laszlo/GCS
> 
> Hi,
> 
> Given it's just a header, I don't think it's necessary to do anything
> complicated - there's nothing to build and there's no dependencies to
> track. No point in having separate packages or cmake files or whatnot -
> #include is all a user needs.
> 

The CMake files aren't _needed_, but they're provided upstream and
downstream projects that use cppzmq and CMake expect them to be there,
and it feels like an unnecessary friction to need to patch/override the
buildsystem of downstream projects to get round us shipping the headers
but not the other parts of the cppzmq distribution.

As observed, I don't know ZMQ that well, so I'm not trying to force
anything if you really don't think this is good idea, but from my
perspective either including the cmake files in libzmq3-dev or splitting
cppzmq into a separate source package which ships them would seem to be a
usability improvement.

> -- 
> Kind regards,
> Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1030045

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2020-10-26 at 11:40 +0000, Gordon Ball wrote:
> On Mon, Oct 26, 2020 at 09:48:52AM +0000, Luca Boccassi wrote:
> > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> > > > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > > > cppzmq repository. However, the associated cmake files are not included,
> > > > which means when trying to build downstream projects which use cppzmq
> > > > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > > > files from cppzmq.
> > >  These are different projects and should be packaged differently. As
> > > czmq is packaged by Luca, I think cppzmq should be packaged by him as
> > > well. But let's hear what he says.
> > > 
> > > Regards,
> > > Laszlo/GCS
> > 
> > Hi,
> > 
> > Given it's just a header, I don't think it's necessary to do anything
> > complicated - there's nothing to build and there's no dependencies to
> > track. No point in having separate packages or cmake files or whatnot -
> > #include is all a user needs.
> > 
> 
> The CMake files aren't _needed_, but they're provided upstream and
> downstream projects that use cppzmq and CMake expect them to be there,
> and it feels like an unnecessary friction to need to patch/override the
> buildsystem of downstream projects to get round us shipping the headers
> but not the other parts of the cppzmq distribution.

Sorry I still don't follow, why does the downstream build system need
to be patched/overriden? Again, it's just a header. There's nothing to
build - just install the package, #include and it's good to go.

> As observed, I don't know ZMQ that well, so I'm not trying to force
> anything if you really don't think this is good idea, but from my
> perspective either including the cmake files in libzmq3-dev or splitting
> cppzmq into a separate source package which ships them would seem to be a
> usability improvement.
> 
> > -- 
> > Kind regards,
> > Luca Boccassi
> 
> 

[toc] | [prev] | [next] | [standalone]

#1030047

On Mon, Oct 26, 2020 at 11:52:17AM +0000, Luca Boccassi wrote:
> On Mon, 2020-10-26 at 11:40 +0000, Gordon Ball wrote:
> > On Mon, Oct 26, 2020 at 09:48:52AM +0000, Luca Boccassi wrote:
> > > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> > > > > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > > > > cppzmq repository. However, the associated cmake files are not included,
> > > > > which means when trying to build downstream projects which use cppzmq
> > > > > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > > > > files from cppzmq.
> > > >  These are different projects and should be packaged differently. As
> > > > czmq is packaged by Luca, I think cppzmq should be packaged by him as
> > > > well. But let's hear what he says.
> > > > 
> > > > Regards,
> > > > Laszlo/GCS
> > > 
> > > Hi,
> > > 
> > > Given it's just a header, I don't think it's necessary to do anything
> > > complicated - there's nothing to build and there's no dependencies to
> > > track. No point in having separate packages or cmake files or whatnot -
> > > #include is all a user needs.
> > > 
> > 
> > The CMake files aren't _needed_, but they're provided upstream and
> > downstream projects that use cppzmq and CMake expect them to be there,
> > and it feels like an unnecessary friction to need to patch/override the
> > buildsystem of downstream projects to get round us shipping the headers
> > but not the other parts of the cppzmq distribution.
> 
> Sorry I still don't follow, why does the downstream build system need
> to be patched/overriden? Again, it's just a header. There's nothing to
> build - just install the package, #include and it's good to go.
> 

This is probably a case where build tools provide you with extra ways to
shoot yourself in the foot. See, for example:

https://github.com/jupyter-xeus/xeus/blob/master/CMakeLists.txt

While the source files do just do `#include <zmq.hpp>`, as you say, the
CMakeLists.txt wants to find the CMake config files for cppzmq to check
for the version, linker flags required, etc:

    set(cppzmq_REQUIRED_VERSION 4.4.1)
    find_package(cppzmq ${cppzmq_REQUIRED_VERSION} REQUIRED)
    target_link_libraries(... PUBLIC ${CPPZMQ_TARGET_NAME} ...)

The CMake files for cppzmq don't (as you'd expect) do much - define a
target which requires linking to libzmq and declare the version.

So, to build the above project against the current debian libzmq3-dev is
possible, but some patching of the downstream package's CMakeLists is
required.

> > As observed, I don't know ZMQ that well, so I'm not trying to force
> > anything if you really don't think this is good idea, but from my
> > perspective either including the cmake files in libzmq3-dev or splitting
> > cppzmq into a separate source package which ships them would seem to be a
> > usability improvement.
> > 
> > > -- 
> > > Kind regards,
> > > Luca Boccassi
> > 
> > 
> 

[toc] | [prev] | [next] | [standalone]

#1030055

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2020-10-26 at 12:28 +0000, Gordon Ball wrote:
> On Mon, Oct 26, 2020 at 11:52:17AM +0000, Luca Boccassi wrote:
> > On Mon, 2020-10-26 at 11:40 +0000, Gordon Ball wrote:
> > > On Mon, Oct 26, 2020 at 09:48:52AM +0000, Luca Boccassi wrote:
> > > > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> > > > > > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > > > > > cppzmq repository. However, the associated cmake files are not included,
> > > > > > which means when trying to build downstream projects which use cppzmq
> > > > > > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > > > > > files from cppzmq.
> > > > >  These are different projects and should be packaged differently. As
> > > > > czmq is packaged by Luca, I think cppzmq should be packaged by him as
> > > > > well. But let's hear what he says.
> > > > > 
> > > > > Regards,
> > > > > Laszlo/GCS
> > > > 
> > > > Hi,
> > > > 
> > > > Given it's just a header, I don't think it's necessary to do anything
> > > > complicated - there's nothing to build and there's no dependencies to
> > > > track. No point in having separate packages or cmake files or whatnot -
> > > > #include is all a user needs.
> > > > 
> > > 
> > > The CMake files aren't _needed_, but they're provided upstream and
> > > downstream projects that use cppzmq and CMake expect them to be there,
> > > and it feels like an unnecessary friction to need to patch/override the
> > > buildsystem of downstream projects to get round us shipping the headers
> > > but not the other parts of the cppzmq distribution.
> > 
> > Sorry I still don't follow, why does the downstream build system need
> > to be patched/overriden? Again, it's just a header. There's nothing to
> > build - just install the package, #include and it's good to go.
> > 
> 
> This is probably a case where build tools provide you with extra ways to
> shoot yourself in the foot. See, for example:
> 
> https://github.com/jupyter-xeus/xeus/blob/master/CMakeLists.txt
> 
> While the source files do just do `#include <zmq.hpp>`, as you say, the
> CMakeLists.txt wants to find the CMake config files for cppzmq to check
> for the version, linker flags required, etc:
> 
>     set(cppzmq_REQUIRED_VERSION 4.4.1)
>     find_package(cppzmq ${cppzmq_REQUIRED_VERSION} REQUIRED)
>     target_link_libraries(... PUBLIC ${CPPZMQ_TARGET_NAME} ...)
> 
> The CMake files for cppzmq don't (as you'd expect) do much - define a
> target which requires linking to libzmq and declare the version.
> 
> So, to build the above project against the current debian libzmq3-dev is
> possible, but some patching of the downstream package's CMakeLists is
> required.

Then why not just fix that project upstream to avoid all that? Sorry,
but I am not going to take on additional work just because of the
arbitrary choice of a downstream build system. Please fix that instead.
Thank you.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1030117

On Mon, Oct 26, 2020 at 01:07:09PM +0000, Luca Boccassi wrote:
> On Mon, 2020-10-26 at 12:28 +0000, Gordon Ball wrote:
> > On Mon, Oct 26, 2020 at 11:52:17AM +0000, Luca Boccassi wrote:
> > > On Mon, 2020-10-26 at 11:40 +0000, Gordon Ball wrote:
> > > > On Mon, Oct 26, 2020 at 09:48:52AM +0000, Luca Boccassi wrote:
> > > > > On Sun, 2020-10-25 at 17:13 +0100, László Böszörményi (GCS) wrote:
> > > > > > On Fri, Oct 23, 2020 at 4:57 PM Gordon Ball <gordon@chronitis.net> wrote:
> > > > > > > src:zeromq3 and libzmq3-dev currently embed headers from the separate
> > > > > > > cppzmq repository. However, the associated cmake files are not included,
> > > > > > > which means when trying to build downstream projects which use cppzmq
> > > > > > > and cmake, it's necessary to hack the buildsystem or embed the cmake
> > > > > > > files from cppzmq.
> > > > > >  These are different projects and should be packaged differently. As
> > > > > > czmq is packaged by Luca, I think cppzmq should be packaged by him as
> > > > > > well. But let's hear what he says.
> > > > > > 
> > > > > > Regards,
> > > > > > Laszlo/GCS
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Given it's just a header, I don't think it's necessary to do anything
> > > > > complicated - there's nothing to build and there's no dependencies to
> > > > > track. No point in having separate packages or cmake files or whatnot -
> > > > > #include is all a user needs.
> > > > > 
> > > > 
> > > > The CMake files aren't _needed_, but they're provided upstream and
> > > > downstream projects that use cppzmq and CMake expect them to be there,
> > > > and it feels like an unnecessary friction to need to patch/override the
> > > > buildsystem of downstream projects to get round us shipping the headers
> > > > but not the other parts of the cppzmq distribution.
> > > 
> > > Sorry I still don't follow, why does the downstream build system need
> > > to be patched/overriden? Again, it's just a header. There's nothing to
> > > build - just install the package, #include and it's good to go.
> > > 
> > 
> > This is probably a case where build tools provide you with extra ways to
> > shoot yourself in the foot. See, for example:
> > 
> > https://github.com/jupyter-xeus/xeus/blob/master/CMakeLists.txt
> > 
> > While the source files do just do `#include <zmq.hpp>`, as you say, the
> > CMakeLists.txt wants to find the CMake config files for cppzmq to check
> > for the version, linker flags required, etc:
> > 
> >     set(cppzmq_REQUIRED_VERSION 4.4.1)
> >     find_package(cppzmq ${cppzmq_REQUIRED_VERSION} REQUIRED)
> >     target_link_libraries(... PUBLIC ${CPPZMQ_TARGET_NAME} ...)
> > 
> > The CMake files for cppzmq don't (as you'd expect) do much - define a
> > target which requires linking to libzmq and declare the version.
> > 
> > So, to build the above project against the current debian libzmq3-dev is
> > possible, but some patching of the downstream package's CMakeLists is
> > required.
> 
> Then why not just fix that project upstream to avoid all that? Sorry,
> but I am not going to take on additional work just because of the
> arbitrary choice of a downstream build system. Please fix that instead.
> Thank you.
> 

I think it is unlikely that they'll be receptive to making such changes
for my benefit, given they have something that works and is supported
by cppzmq upstream.

However, the workarounds for not having CMake integration in this case
aren't too complicated, so I'll work on that instead.
> -- 
> Kind regards,
> Luca Boccassi

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web