On 9/6/21 2:41 PM, Дмитрий Архипов via Boost wrote:

пн, 6 сент. 2021 г., 14:03 Sreeraj K via Boost :

...

*[I initialially raised this question in https://github.com/boostorg/boost/issues/548 https://github.com/boostorg/boost/issues/548, but @mclaw recommended this mailing list.]*

Similar to many other packages (eg: curl, krb5, pcre, xml2, xslt etc..), can we also ship boost-config that would provide the installation options ?

We can probably start with something like this ?

$ /usr/bin/boost-config --help Usage: boost-config [ options ]

Options: --cflags print compiler options --ldflags print linker options --prefix print the boost prefix --version print the boost version --help print this usage summary

$ /usr/bin/boost-config --version 1.66.0 $ /usr/bin/boost-config --cflags -I/usr/include $ /usr/bin/boost-config --ldflags -L/usr/lib64 -Wl,-R/usr/lib64

This sounds like a pkg-config package. In fact, several projects moved from

such custom scripts to pkg-config.

Anyway, the main problem here is to make the build system (b2) output those

flags in a parseable manner. If that was implemented, it could be used to

make pkg-config packages, CMake config modules, etc.

Another problem is that different boost libraries will require different

build flags to use them, so you'll actually need e.g. boost-thread-config,

boost-filesystem-config (or boost-thread.pc and boost-filesystem.pc if

pkg-config is used).

I agree that pkg-config is the right way. I believe, we're already producing CMake scripts for aiding find_package, but that is limited to CMake usage. There's this old ticket: https://svn.boost.org/trac10/ticket/1094 I'm not sure if there was any real progress since then.

On Mon, Sep 6, 2021 at 8:11 AM Дмитрий Архипов via Boost < boost@lists.boost.org> wrote:

A significant difference between generating a CMake config module and a .pc file is that CMake config modules (usually) declare targets and set their properties. .pc files contain actual flags to pass to a compiler. I've skimmed through boost-install.jam and it appears to convert b2 properties to CMake properties. For .pc files one would have to either pick a compiler for a similar translation or implement some mechanism in b2 to be able to do it for any compiler. In the latter case, most likely every compiler toolset module would have to be updated to support that.

If people are willing to add pkg-config targets to their build specifications (could be "automated for Boost use case) it would be fairly easy to take the usage requirements of the library target and put those in the .pc file generated. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net