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