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 <gor...@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 > > > > >
