Arch Linux

Neurofibromin

Member

Registered: 2023-12-16

Posts: 8

soplex missing papilo as a runtime dependency (header include)

The soplex package appears to have been built with papilo support enabled. Because of this, the exported header /usr/include/soplex/fmt.hpp defaults to including headers provided by the papilo package.

Papilo is currently only listed as a makedepends. When soplex is installed and i attempt to compile a program against it, the compilation fails because papilo headers are missing from my system.

Reproduce with this minimal program:

1) sudo pacman -S soplex

2) write the below to a main.cpp file

#include <iostream>
#include <soplex.h>
#include <soplex/fmt.hpp>

int main() {
    std::cout << "Version: " << soplex::SoPlex::getVersionString() << std::endl;
    fmt::print("soplex/fmt.hpp\n");
    return 0;
}

3) try to compile it:
g++ -std=c++17 -Wall -Wextra main.cpp -o test_soplex -lsoplex

4) error:
g++ -std=c++17 -Wall -Wextra main.cpp -o test_soplex -lsoplex
In file included from /usr/include/soplex/spxout.h:34,
                 from /usr/include/soplex/spxalloc.h:36,
                 from /usr/include/soplex/idxset.h:32,
                 from /usr/include/soplex/ssvectorbase.h:35,
                 from /usr/include/soplex/basevectors.h:40,
                 from /usr/include/soplex.h:36,
                 from main.cpp:2:
/usr/include/soplex/fmt.hpp:55:10: fatal error: papilo/external/fmt/format.h: No such file or directory
   55 | #include "papilo/external/fmt/format.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Sorry to report bugs here, I could not get an account at the gitlab.

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 549

Re: soplex missing papilo as a runtime dependency (header include)

boost package is also required but not listed as a dependency:

In file included from /usr/include/soplex.h:35,
                 from main.cc:2:
/usr/include/soplex/spxdefines.h:63:10: fatal error: boost/multiprecision/number.hpp: No such file or directory
   63 | #include "boost/multiprecision/number.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

arojas

Developer

From: Spain

Registered: 2011-10-09

Posts: 2,286

Re: soplex missing papilo as a runtime dependency (header include)

Sorry to report bugs here, I could not get an account at the gitlab.

There is not a clear policy on whether header dependencies should be runtime dependencies of a package, so this is not a bug but a deliberate packaging decision.

Neurofibromin

Member

Registered: 2023-12-16

Posts: 8

Re: soplex missing papilo as a runtime dependency (header include)

Sorry to report bugs here, I could not get an account at the gitlab.

There is not a clear policy on whether header dependencies should be runtime dependencies of a package, so this is not a bug but a deliberate packaging decision.

Feels like a decision that goes against user expectation. Not to be too opinionated, but I would expect to not get an error when including a header I installed.

arojas

Developer

From: Spain

Registered: 2011-10-09

Posts: 2,286

Re: soplex missing papilo as a runtime dependency (header include)

Sorry to report bugs here, I could not get an account at the gitlab.

There is not a clear policy on whether header dependencies should be runtime dependencies of a package, so this is not a bug but a deliberate packaging decision.

Feels like a decision that goes against user expectation. Not to be too opinionated, but I would expect to not get an error when including a header I installed.

You didn't install a header, you installed a package that contains an executable, a shared library and its headers. A very small percentage of users that install the package will actually compile something with it, not pulling the whole 150 MB of boost with it is a reasonable decision, I'd say.

dimich

Member

From: Kharkiv, Ukraine

Registered: 2009-11-03

Posts: 549

Re: soplex missing papilo as a runtime dependency (header include)

Technically a library can be split into two packages: one "runtime" with shared objects, another "devel" with headers and possibly static libraries. However, there also may be cases when headers from third-party package are required only in certain build configurations, so this is not a universal solution.
CMake, for example, has concept of private/public dependencies for libraries, this allows to manage dependency visibility by configuration flags. But package manager is not a build system generator. I think it would be a big burden to implement something similar for packages.