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. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
