Mailinglist Archive: opensuse-packaging (48 mails)

< Previous Next >
Re: [opensuse-packaging] Packaging a (mostly) header only C++ library
Adam Mizerski <adam@xxxxxxxxxxx> writes:

W dniu 19.12.2018 o 23:45, Dan Čermák pisze:
Adam Mizerski <adam@xxxxxxxxxxx> writes:

W dniu 18.12.2018 o 12:22, Dan Čermák pisze:
Martin Pluskal <martin@xxxxxxxxxxx> writes:

On Tue, 2018-12-18 at 10:41 +0100, Dan Čermák wrote:
Hi list,

I would like to package a (kind-of) header only C++ library
(https://github.com/emilk/loguru). The problem is, that it actually
ships a cpp file in it's source tree (so I guess it needs to be
compiled
to a shared library?).

The issue at hand is, that loguru is designed to be embedded in your
C++
project (there is *a lot* of compile time switches) and even running
the
test suite from a shared library requires a lot of patching of the
source tree.

What would be the correct procedure for packaging? Create a shared
library nevertheless? Or create multiple libraries with some common
compile time switches? Or just install the sources into the file
system?
Hi

I guess you mean something like installing just headers like in i.e [1]
- if so just having -devel subpackage is absolutely ok.

Yes, kind of. The difference is however that loguru ships a cpp file and
not just headers.

I would personally prefer to just ship the sources, as upstream clearly
wants it that way.


I see no problem with packaging this as a shared library.

There is a practical problem:
the library provides multiple compile time switches, that are intended
to be set by the user of the library. Most of these only add features,
so they can (probably) be enabled in a shared library (I'll check that
to be sure). But there are switches (like LOGURU_USE_FMTLIB) which are
not a pure addition but actual switches, so we would essentially have to
hardcode these.

Bummer. LOGURU_USE_FMTLIB is a little problem. There are other macros
that are integer variables, so making a library with every possible
combination is out of question. Bad design IHMO, but as packagers, we're
not here to judge.

Yeah, bummer indeed. Given the use case of the library (be as simple as
possible to include, especially on platforms like Windows) it makes
sense, since you'll either use fmtlib or you won't. Still sucks for us.

I'll ask upstream if they would consider making these switches
compatible with building a single shared library.


Is that a viable approach? Maybe coupled with patching the source file
so that the compiler produces an error if you define that macro?

Otherwise it
makes not much sense to package it at all, I think.

It would add a little convenience. And I plan on packaging other
software that depends on loguru.

I (now) think that the software that uses loguru, should do as the
library authors intended: include a copy in it's sources.

I can't find it written anywhere now, but as I remember, the general
rule is that software should not contain it own copies of libraries, and
if they do, they should be patched to use shared libraries. The
exception is when bundled copy of library is modified in any way that
makes it incompatible with original. I think loguru by design falls into
the exceptional category.

I took a look at the software that I plan to package (the one that uses
loguru) and it sets none of the compile time switches, so it could work
with a shared library libloguru-2.0.0.so.


Adam Mizerski

--
Dan Čermák <dcermak@xxxxxxxx>
Software Engineer Development tools
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
< Previous Next >