Can we create boost-config
*[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 Thanks.
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). пн, 6 сент. 2021 г., 14:03 Sreeraj K via Boost <boost@lists.boost.org>:
*[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
Thanks.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/6/21 2:41 PM, Дмитрий Архипов via Boost wrote:
пн, 6 сент. 2021 г., 14:03 Sreeraj K via Boost <boost@lists.boost.org>:
*[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.
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. пн, 6 сент. 2021 г., 14:53 Andrey Semashev via Boost <boost@lists.boost.org
:
пн, 6 сент. 2021 г., 14:03 Sreeraj K via Boost <boost@lists.boost.org>:
*[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
On 9/6/21 2:41 PM, Дмитрий Архипов via Boost wrote: 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
participants (4)
-
Andrey Semashev -
René Ferdinand Rivera Morell -
Sreeraj K -
Дмитрий Архипов