W dniu 18.12.2018 o 12:22, Dan Čermák pisze:

Martin Pluskal <martin@pluskal.org> 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. Otherwise it makes not much sense to package it at all, I think. Since it's a single cpp file, you don't need any build system. Just write a single gcc command it spec file. Shared library should be named libloguru-2.0.0.so and shipped in package libloguru-2_0_0. See https://en.opensuse.org/openSUSE:Shared_library_packaging_policy Adam Mizerski

W dniu 19.12.2018 o 23:45, Dan Čermák pisze:

Adam Mizerski <adam@mizerski.pl> writes:

...

W dniu 18.12.2018 o 12:22, Dan Čermák pisze:

...

Martin Pluskal <martin@pluskal.org> 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.

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

Adam Mizerski <adam@mizerski.pl> writes:

W dniu 19.12.2018 o 23:45, Dan Čermák pisze:

...

Adam Mizerski <adam@mizerski.pl> writes:

...

W dniu 18.12.2018 o 12:22, Dan Čermák pisze:

...

Martin Pluskal <martin@pluskal.org> 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@suse.com> 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)