Re: [paho-dev] Paho C and C++ build systems

[Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx>]

After watching a dozen YouTube videos on the subject, my take is that
"Modern CMake" is mostly about improved modularity. Mainly that each
library is able to contain its settings without having global variable
leak into or out of it, and that it's "interface" (where its headers and
libraries live, for example) is clearly defined and easy to use by any
application that wants to link the library.

More inline...

On 9/1/20 11:58 AM, Greg Troxel wrote:
> 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.

Agreed, though it seems like there's finally an effort on the part of
the CMake folks to start preaching about what bad/old techniques need to
be deprecated, and how they should be replaced in current projects.



>
>> 2. Properly handle transient dependencies
> I don't know what that means.

This is mainly a CMake thing... make it easy for apps and higher-level
libraries to find and link their dependencies in their build systems,
assuming that those also use CMake.

That means, basically, if an application wants to use Paho C++, it
shouldn't need to know or care (too much) that the library, in turn,
needs the Paho C lib underneath. To help out end users, the Paho C++ lib
should do the hard work of finding the C lib and then passing those
results back up to the app's build system as to what additional
libraries are needed.


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

Yes on all counts. The C++ lib is a separate project that wraps the C
library.

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

Yes, that's part of what needs to be done.

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

Yeah, it's C++11.

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

Some of that is in the C lib, but not yet in the C++ library. So that's
on the list.

Frank