Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Back to the top