| Re: [paho-dev] Paho C and C++ build systems |
Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx> writes: > I'd like to spend a little time in the near future getting the CMake > build systems for the Paho C and C++ libraries fixed and modernized. A > huge percentage of the requests I'm getting lately are just about how to > build and install the libraries. I know there's also a push lately to > just get the projects into Conan and/or create installable packages, but > fixing the CMake would help there, too. Packaging is important, but I think projects need to focus on having a build system that is well documented and that works correctly. Then making a package is relatively easy. (I work on pkgsrc, which packages many things, include Paho python and mosquitto.) > What I would like to do is: > 1. Get the build systems of both projects up-to-date with current, > modern, modular CMake best practices. I am unclear on what cmake people think is best practice, but I will suggest that this includes "There are no (or minimal) switches by OS in the cmaekfiles. Instead, there are feature tests." This means that it is far more likely to work on other operating systems. I see a lot of cmakefiles that have lists of OS and have to be patched every time you compile it on a new OS, for no good reason. autoconf culture got this right; cmake lets you get it right but there seems to be a culture of doing it wrong. > 2. Properly handle transient dependencies I don't know what that means. > 3. Properly export the installs with consistent naming, etc > 4. Have the C++ lib automatically build the C lib if not found Are Paho C and Paho C++ separate projects? If so, does the C++ one depend on the C one? Separate tarballs? Separate install targets? From a packaging viewpoint, what is ideal is if there is a tarball that can build, test and install the C library. Then one to build C++ and if C++ needs the C lib (because it's a wrapper, instead of being an implementation in C++), then it should expect it to be installed. An alternative view is that there is one package, which is both C and C++ and just builds both. C++ is fairly normal, although C++11 is a barrier in many environments still I suspect. So I would not be a big fan of this. Another thing is tests. People should be able to run the tests easily. Also, see autoconf/automake's notion of "make dist" to make a distribution tarball, and "make distcheck" to unpack that tarball and do an objdir build of it and then run the tests. cmake culture appears not to do this. Doesn't need to be in cmake per se, as long as it's a shell script (/bin/sh, POSIX, not bash, per the usual portability norms).
Attachment:
signature.asc
Description: PGP signature