feature wish for boost 1.32.1 or 1.33.0: pkg-config support
Hi Boosters, I am using boost in several projects now, and some of these projects will be released as open source. So they will have a configure script that checks the compiling host, and which should report missing libraries. I saw many open source projects adding boost to their source code tree directly, thus these projects dont have to check the proper boost versions, or library names. That solve the problem, but thats not a fine solution. To simplify using boost libraries i would like to see boost supporting pkg-config or a different maybe better approach which fits better to boost's needs. But first I would like to explain how pkg-config works, and how pkg-config makes using librariers simple. The pkg-config package can be found here: http://pgk-config.freedesktop.org/wiki/Software_2fpkgconfig It seems to work on all unix systems and windows. The pkg-config script parses .pc files from several locations in the system, and allows querrying the existance, version, compiler flags and linker flags of installed libraries. For example the gtkmm-2.0.pc file looks like that on suse systems: prefix=/opt/gnome exec_prefix=${prefix} libdir=/opt/gnome/lib includedir=${prefix}/include Name: GTKmm Description: C++ wrapper for GTK+ Requires: glibmm-2.0 gdkmm-2.0 pangomm-1.0 atkmm-1.0 gtk+-2.0 Version: 2.2.8 Libs: -L${libdir} -lgtkmm-2.0 Cflags: -I${includedir}/gtkmm-2.0 -I${libdir}/gtkmm-2.0/include Thus when running 'pkg-config --libs gtkmm-2.0' One gets the output: -Wl,--export-dynamic -L/opt/gnome/lib -lgtkmm-2.0 -lgdkmm-2.0 -latkmm-1.0 -lgtk-x11-2.0 -lpangomm-1.0 -lglibmm-2.0 -lsigc-1.2 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 which can be used to link a gtkmm application to all libraries needed. With the help of pkg-config can write simple makefiles, or build scripts which execute pkg-config directly. But pkg-config also comes with a nice m4 script to invoke it properly with autoconf. PKG_CHECK_MODULES(GTKMM, gtkmm-2.0, ,[AC_MSG_ERROR("Gtkmm-2.0 missing")]) I am not sure how to provide transparent support for different toolsets, and there is no way to specify further flags, like mt debug ... So qt for example has adds two files qt.pc and qt-mt.pc. So maybe pkg-config is not the right tool for boost. But at least for a large amount of the gcc-boost users it would be fine. Maybe boost could provide a similar facility for autotools. So maybe a small "boost-config" that gets flags like toolset, debug-switch, a version range descriptor, and then prints the compiler and/or linker flags. And a small m4/shell script that makes invoking that tool even simpler. Regards Andreas Pokorny
First, I would say, there is a need for a better autoconf for boost. There has been some interest in scons, and scons also includes some capability here that might be useful. I don't think pkg-config is the right tool. All it is for is to record the settings that were used to build packages - it doesn't figure them out. I don't see how that would help boost.
Hi, On Wed, Dec 15, 2004 at 08:38:37AM -0500, "Neal D. Becker" <ndbecker2@verizon.net> wrote:
First, I would say, there is a need for a better autoconf for boost. There has been some interest in scons, and scons also includes some capability here that might be useful. autoconf is a tool for configuring builds, scons is a complete build system. Both things do not help when writing an application that uses boost.
I don't think pkg-config is the right tool. All it is for is to record the settings that were used to build packages - it doesn't figure them out. I don't see how that would help boost. That was no "please replace bjam with <buildtool>"-email. I was talking about helping poeple who want to use boost, and integrate that into the build system they use.
Regards Andreas Pokorny
Andreas Pokorny wrote:
Hi,
On Wed, Dec 15, 2004 at 08:38:37AM -0500, "Neal D. Becker" <ndbecker2@verizon.net> wrote:
First, I would say, there is a need for a better autoconf for boost. There has been some interest in scons, and scons also includes some capability here that might be useful. autoconf is a tool for configuring builds, scons is a complete build system. Both things do not help when writing an application that uses boost.
I was referring to the fact that recent scons has added an autoconf-like functionality.
I don't think pkg-config is the right tool. All it is for is to record the settings that were used to build packages - it doesn't figure them out. I don't see how that would help boost. That was no "please replace bjam with <buildtool>"-email. I was talking about helping poeple who want to use boost, and integrate that into the build system they use.
So, do you mean you want to use pkg-config to record the settings that were used to build boost? If so, I misunderstood. This might be useful.
On 12/15/2004 09:45 AM, Neal D. Becker wrote:
So, do you mean you want to use pkg-config to record the settings that were used to build boost? If so, I misunderstood. This might be useful.
I've been wanting something that would also record the variants of the files used to build a particular main target also. For example, something like: <------------- 1.1 Makefile 1.1 basic_targets.imk 1.1 boost-root.ln/boost/config.hpp 1.1 boost-root.ln/boost/config/compiler/gcc.hpp 1.1 boost-root.ln/boost/config/platform/linux.hpp ... 1.3 boost-root.ln/development/boost/dyn_inherit/dynamic_base.hpp 1.2 boost-root.ln/development/boost/dyn_inherit/virtual_dtor_abs.hpp
------------- recorded in file:
boost-root.ln\ /release/gcc/debug\ /libs/grammar_pipeline/test/base/productions.release.log {where: 1) the trailing \ indicate line concatenation as in unix 2) the 2nd line indicates how the release was built, much like boost-build does with it's directory naming convention 3) the 2nd line indicates what release was built, again much like boost-build } corresponding to the main target: productions.cpp in the corresponding test directory: boost-root.ln\ /libs/grammar_pipeline/test/base The column 1 numbers in the release.log are the RCS version numbers. Since the log files can be versioned, this allows a simple comparison between the *.release.log files to see which files have changed between releases. Also, using *.release.log.~i.j~ and the information provided by pkg-config (IIUC) you can recreate the productions.exe file as it was on the date corresponding to *.release.log.~i.j~ . Also, the log entries for release.log files is a convenient place to summarize the reason for changes. I know you can tag each of the RCS (or CVS) files with some version number; however, the above seems more intuitive to me.
On Wed, Dec 15, 2004 at 08:38:37AM -0500, Neal D. Becker wrote:
First, I would say, there is a need for a better autoconf for boost. There has been some interest in scons, and scons also includes some capability here that might be useful.
I don't think pkg-config is the right tool. All it is for is to record the settings that were used to build packages - it doesn't figure them out. I don't see how that would help boost.
They're useful for other libraries or applications that rely on Boost to be able to generate Makefiles. It doesn't help Boost at all, but if I write a library that uses Boost and I want to use autoconf and automake then I can tell autoconf to use pkg-config in order to figure out the compiler and linker args to use to find Boost. This means the user can run "configure" and not have to say "configure --with-boost=/usr/local/boost/" or similar, configure will run pkgconfig and determine that info itself. The only problem with this approach I can see is that Boost consists of *lots* of libraries, not a single libboost.so - so IIUC there would have to be pkgconfig files for each lib, and possibly for each combination of toolset, debug/release, ST/MT, for each lib! This might be something that packagers should add themselves if they ship a single, pre-packaged, system-wide Boost. (By which I mean, RedHat could add pkgconfig to their boost RPM, because they only ship a single libboost_regex.so, not libboost_regex-gcc-mt-1_32.so and other toolset/build/thread combos). Otherwise autoconf would have to ask pkgconfig for the paths to a specific build for a specific toolset for a specific build, which makes it completely unportable to other toolsets/builds etc. Another, related option, is a boost-config script that allows you to specify which libs you want, and which versions, e.g. boost-config thread regex signals --libs might output: -L/usr/lib/ -lboost_regex -lboost_thread -lboost_signals and boost-config regex --libs --toolset=gcc --build=mt might output: -L/usr/lib/ -lboost_regex-gcc-mt-1_32 A number of projects I know provide a file like this, which is almost as easy to use in autoconf/automake as pkgconfig (there are standard macros for using such a file in place of pkgconfig). jon -- "Most people would sooner die than think; in fact, they do so." - Bertrand Russell
On Wed, 15 Dec 2004 17:13:44 +0000 Jonathan Wakely <cow@compsoc.man.ac.uk> wrote
Another, related option, is a boost-config script that allows you to specify which libs you want, and which versions, e.g. boost-config thread regex signals --libs might output: -L/usr/lib/ -lboost_regex -lboost_thread -lboost_signals
and boost-config regex --libs --toolset=gcc --build=mt might output: -L/usr/lib/ -lboost_regex-gcc-mt-1_32
An option that also emits all the compilation flags that were used to compile the library would be nice too, to make sure compiles are done the same way...
On Wed, 15 Dec 2004 12:29:14 -0500, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
An option that also emits all the compilation flags that were used to compile the library would be nice too, to make sure compiles are done the same way...
Thats what pkg-config --cflags is for. -- Caleb Epstein caleb dot epstein at gmail dot com
On Wed, Dec 15, 2004 at 12:49:21PM -0500, Caleb Epstein wrote:
On Wed, 15 Dec 2004 12:29:14 -0500, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
An option that also emits all the compilation flags that were used to compile the library would be nice too, to make sure compiles are done the same way...
Thats what pkg-config --cflags is for.
I though that emits the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself. Have I confused myself again? jon -- "Accept the contradictions" - The KLF
On Thu, 16 Dec 2004 10:19:36 +0000, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
On Wed, Dec 15, 2004 at 12:49:21PM -0500, Caleb Epstein wrote:
On Wed, 15 Dec 2004 12:29:14 -0500, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
An option that also emits all the compilation flags that were used to compile the library would be nice too, to make sure compiles are done the same way...
Thats what pkg-config --cflags is for.
I though that emits the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself.
I guess that is the case, but what would the difference be between the two? The only thing that springs immediately to mind would be preprocessor macros that would turn on e.g. __declspec(dllexport). -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
An option that also emits all the compilation flags that were used to compile the library would be nice too, to make sure compiles are done the same way...
Thats what pkg-config --cflags is for.
I though that emits the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself.
I guess that is the case, but what would the difference be between the two?
The only thing that springs immediately to mind would be preprocessor macros that would turn on e.g. __declspec(dllexport).
There are a number of flags that have to be made public, such as what type of runtime to use (that could mean, among others, the definition of __REENTRANT or the '-pthread' compiler flag). Also, on some platforms the dependency on dynamic libraries isn't well encapsulated, i.e. if libA.so depends on libB.so, an executable linking against libB.so also needs to be linked (explicitely) against libA.so. There is quite some variation between different platforms, and pkg-config tries to make life a bit easier for developers of portable code. Regards, Stefan
On Thu, 16 Dec 2004 08:44:20 -0500, Stefan Seefeld <seefeld@sympatico.ca> wrote:
There are a number of flags that have to be made public, such as what type of runtime to use (that could mean, among others, the definition of __REENTRANT or the '-pthread' compiler flag). Also, on some platforms the dependency on dynamic libraries isn't well encapsulated, i.e. if libA.so depends on libB.so, an executable linking against libB.so also needs to be linked (explicitely) against libA.so. There is quite some variation between different platforms, and pkg-config tries to make life a bit easier for developers of portable code.
I understand all this. I was following up to Jon asking what the differnce would be between: "the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself." -- Caleb Epstein caleb dot epstein at gmail dot com
On Thu, Dec 16, 2004 at 09:50:36AM -0500, Caleb Epstein wrote:
On Thu, 16 Dec 2004 08:44:20 -0500, Stefan Seefeld <seefeld@sympatico.ca> wrote:
There are a number of flags that have to be made public, such as what type of runtime to use (that could mean, among others, the definition of __REENTRANT or the '-pthread' compiler flag). Also, on some platforms the dependency on dynamic libraries isn't well encapsulated, i.e. if libA.so depends on libB.so, an executable linking against libB.so also needs to be linked (explicitely) against libA.so. There is quite some variation between different platforms, and pkg-config tries to make life a bit easier for developers of portable code.
I understand all this. I was following up to Jon asking what the differnce would be between: "the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself."
Sorry, I hadn't had a chance to think of anything. You might have compiled Boost with a certain level of optimisation, say by setting GXX="g++ -O3" (for the GCC toolset) but you don't necessarily want to optimise your code at that level (if at all) so --cflags should not emit -O3. Similarly for -ansi, -pedantic, -W and other switches that don't affect the ABI or whether you can link to a library safely. Or is that irrelevant? jon -- "The optimist believes this is the best of all possible worlds, and the pessimist fears this is so..." - H. Allen Smith
Jonathan Wakely wrote:
You might have compiled Boost with a certain level of optimisation, say by setting GXX="g++ -O3" (for the GCC toolset) but you don't necessarily want to optimise your code at that level (if at all) so --cflags should not emit -O3. Similarly for -ansi, -pedantic, -W and other switches that don't affect the ABI or whether you can link to a library safely.
Just so you know, Boost.Build v2 can handle all this with something we call usage-requirements. It would be smart of us to have the rules that do installation also create small Jamfiles containing the appropriate descriptions of prebuilt targets. The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and... I think the answer is that we (the BB maintainers) should only feel responsible for generating the Jamfiles, and we should invite interested parties to submit Boost.Build support for the other things. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and...
I don't think comparing pkg-config to Jamfiles (or Makefiles for that matter) is very meaningful, as pkg-config is just a tiny tool to be used by arbitrary build systems. On the other hand, providing a Jamfile pretty much requires the user to use a bjam (or even BB ?) based build system, or am I missing something ?
I think the answer is that we (the BB maintainers) should only feel responsible for generating the Jamfiles, and we should invite interested parties to submit Boost.Build support for the other things.
I'm not the right person to tell BB developers what their responsibility is, but I believe providing a more neutral way to access required compiler flags for easy integration into *any* build system would be very much appreciated by everybody. Thanks, Stefan
Stefan Seefeld wrote:
David Abrahams wrote:
The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and...
I don't think comparing pkg-config to Jamfiles (or Makefiles for that matter) is very meaningful, as pkg-config is just a tiny tool to be used by arbitrary build systems. On the other hand, providing a Jamfile pretty much requires the user to use a bjam (or even BB ?) based build system, or am I missing something ?
No, I think you're correct.
I think the answer is that we (the BB maintainers) should only feel responsible for generating the Jamfiles, and we should invite interested parties to submit Boost.Build support for the other things.
I'm not the right person to tell BB developers what their responsibility is, but I believe providing a more neutral way to access required compiler flags for easy integration into *any* build system would be very much appreciated by everybody.
I see your point. I guess once you're dealing with a particular prebuilt file, there's little need for a platform-/compiler-neutral description of how it was built. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Stefan Seefeld wrote:
I'm not the right person to tell BB developers what their responsibility is, but I believe providing a more neutral way to access required compiler flags for easy integration into *any* build system would be very much appreciated by everybody.
I see your point. I guess once you're dealing with a particular prebuilt file, there's little need for a platform-/compiler-neutral description of how it was built.
my understanding of this whole thread so far is that indeed there is such a need. It's not about what was needed to get where we are but about what is needed to make the current status (i.e. prebuilt boost libraries) useable to compile end-products. You already encode part of that information into the library names. But a) that's not enough to regenerate the whole set of flags (compiler and linker) that still need to be known, and b) there is no way to automatize that recovery process and hook it up with end-user build systems. Regards, Stefan
Stefan Seefeld wrote:
David Abrahams wrote:
Stefan Seefeld wrote:
I'm not the right person to tell BB developers what their responsibility is, but I believe providing a more neutral way to access required compiler flags for easy integration into *any* build system would be very much appreciated by everybody.
I see your point. I guess once you're dealing with a particular prebuilt file, there's little need for a platform-/compiler-neutral description of how it was built.
my understanding of this whole thread so far is that indeed there is such a need.
Reread what I wrote. I believe there's a need for a description, but a compiler- and platform- neutral abstract description (which a Jamfile is) is not as useful as one that just gives concrete information about how the actual target was -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Stefan Seefeld wrote:
my understanding of this whole thread so far is that indeed there is such a need.
Reread what I wrote. I believe there's a need for a description, but a compiler- and platform- neutral abstract description (which a Jamfile is) is not as useful as one that just gives concrete information about how the actual target was "built."--------------------^
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Thu, 16 Dec 2004 10:42:13 -0500 David Abrahams <dave@boost-consulting.com> wrote:
The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and...
I think the answer is that we (the BB maintainers) should only feel responsible for generating the Jamfiles, and we should invite interested parties to submit Boost.Build support for the other things.
Right. However, the main problem is not which build tool I use, but how I can integrate the boost libraries into my build process. Specifically, I must build my code with the same flags and options that boost is built. If my project does not use jamfiles, this is very difficult, because I have no way of knowing what options to use. In a large project, I may be using several different libraries, each built with a different build system. To me, that is ok, as long as there is some way for me to grab those options from some other program or script so that I can incorporate them into my other builds. I do not think anyone is suggesting that Boost support all build environments. Instead, I think people are wanting a way to extract the build information in an easy manner. For example, a big help would be to go to the root of boost, and call bjam just like I would to build my libraries, except pass in another option that is interpreted as "Pretend to build each library, but instead of actually doing the build steps, spit out all the build options for each library." Maybe that is what you were describing earlier, but instead of it being a jam file, maybe something more like a simple config file containing compile and link options for each library.
Jody Hagins wrote:
On Thu, 16 Dec 2004 10:42:13 -0500 David Abrahams <dave@boost-consulting.com> wrote:
The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and...
I think the answer is that we (the BB maintainers) should only feel responsible for generating the Jamfiles, and we should invite interested parties to submit Boost.Build support for the other things.
Right. However, the main problem is not which build tool I use, but how I can integrate the boost libraries into my build process. Specifically, I must build my code with the same flags and options that boost is built. If my project does not use jamfiles, this is very difficult, because I have no way of knowing what options to use. In a large project, I may be using several different libraries, each built with a different build system. To me, that is ok, as long as there is some way for me to grab those options from some other program or script so that I can incorporate them into my other builds.
I do not think anyone is suggesting that Boost support all build environments. Instead, I think people are wanting a way to extract the build information in an easy manner. For example, a big help would be to go to the root of boost, and call bjam just like I would to build my libraries, except pass in another option that is interpreted as "Pretend to build each library, but instead of actually doing the build steps, spit out all the build options for each library."
bjam -n -a -n == don't actually build anything, but print the commands used. -a == act like everything is out of date and needs to be rebuilt -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Jody Hagins wrote:
On Thu, 16 Dec 2004 10:42:13 -0500 David Abrahams <dave@boost-consulting.com> wrote:
The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and...
I think the answer is that we (the BB maintainers) should only feel responsible for generating the Jamfiles, and we should invite interested parties to submit Boost.Build support for the other things.
Right. However, the main problem is not which build tool I use, but how I can integrate the boost libraries into my build process. Specifically, I must build my code with the same flags and options that boost is built. If my project does not use jamfiles, this is very difficult, because I have no way of knowing what options to use.
Of course the answer to that is simple: use Boost.Build ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Thu, Dec 16, 2004 at 10:42:13AM -0500, David Abrahams wrote:
The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and...
I do get your point ... ... but I think it's necessary to say that autoconf has support for pkg-config and Makefile support for pkg-config is trivial. So in the particular case of Unix and Unix-like builds (not using BBv2) pkg-config support is enough is enough to address its needs. Marcelo
On Thu, Dec 16, 2004 at 10:42:13AM -0500, David Abrahams <dave@boost-consulting.com> wrote:
The only real problem now is that there are a plethora of different build / configuration systems out there. Should BBv2 try to cater to each one? We could generate pkg-config files in addition to Jamfiles, oh and we could generate Makefiles and autoconf files and Visual Studio Projects and Metrowerks projects and... Nope of course not, pkg-config, or the boost-config would allow simple support of custom writen makefiles, autoconf, scons, and whatever build system allows calling applications and evaluating its output. This is a small step for boost, but a huge step for all boost users out there!
I think the answer is that we (the BB maintainers) should only feel responsible for generating the Jamfiles, and we should invite interested parties to submit Boost.Build support for the other things. Ok I am an intersted party, how can I get infos like the path to the installed libraries, the successfully built targets, the toolset used ...?
I plan to write a small application that opens from a dedicated directory e.g. prefix/lib/boost-config/ all files, where each one contains build and install information of a deployment of boost. This will allow having several versions of boost, or boost with different toolsets installed on a single system. Regards Andreas Pokorny
On Thu, Dec 16, 2004 at 10:19:36AM +0000, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote:
On Wed, Dec 15, 2004 at 12:49:21PM -0500, Caleb Epstein wrote:
On Wed, 15 Dec 2004 12:29:14 -0500, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
An option that also emits all the compilation flags that were used to compile the library would be nice too, to make sure compiles are done the same way...
Thats what pkg-config --cflags is for.
I though that emits the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself.
Have I confused myself again? No you are right, thats exactly what i was asking for.
I now see that my first mail was too vague. I am really sorry for that. Regards Andreas Pokorny
On Thu, Dec 16, 2004 at 10:19:36AM +0000, Jonathan Wakely wrote:
I though that emits the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself.
You can store arbitrary variables in .pc files and retrieve them using pkg-config --variable=name. The only trick here is to define the name of the package or packages and make that consistent across all systems. It's no use to have boost-redhat.pc and boost-darwin.pc because that's precisely the point of pkg-config. boost.pc and boost-signals.pc and boost-regex.pc are all fine. Marcelo
On Sun, Dec 26, 2004 at 09:27:04PM -0600, "Marcelo E. Magallon" <mmagallo@debian.org> wrote:
On Thu, Dec 16, 2004 at 10:19:36AM +0000, Jonathan Wakely wrote:
I though that emits the flags that /should/be/ used to compile against Boost, not the flags the /were/ used to compile Boost itself.
You can store arbitrary variables in .pc files and retrieve them using pkg-config --variable=name. The only trick here is to define the name of the package or packages and make that consistent across all systems. Thats not enough, the return values of pkg-config must be dependant on the toolset setting, and a few flags like debug, multithreaded..
It's no use to have boost-redhat.pc and boost-darwin.pc because that's precisely the point of pkg-config. boost.pc and boost-signals.pc and boost-regex.pc are all fine. Sure boost has to provide these files. The current situation is unbearable.
Regards Andreas Pokorny
On Sat, Jan 01, 2005 at 09:46:22PM +0100, Andreas Pokorny wrote:
You can store arbitrary variables in .pc files and retrieve them using pkg-config --variable=name. The only trick here is to define the name of the package or packages and make that consistent across all systems. Thats not enough, the return values of pkg-config must be dependant on the toolset setting, and a few flags like debug, multithreaded..
If you require something like that, then several boost.pc files is the correct solution. You just need to have a sane way of finding out which targets are available. And you can use pkg-config --variable=name for that. In fewer words, make: $ pkg-config --foo boost-signals do something useful. Need to note that --define-variable is also available, and the output of e.g. --libs is interpolated. Marcelo
Hi, On Wed, Dec 15, 2004 at 05:13:44PM +0000, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote: [snip]
The only problem with this approach I can see is that Boost consists of *lots* of libraries, not a single libboost.so - so IIUC there would have to be pkgconfig files for each lib, and possibly for each combination of toolset, debug/release, ST/MT, for each lib! Exactly, thats why pkg-config might not be the right tool. I would suggest that the features of pkg-config get extended by boost needs. ( extend => reimplement as boost application ) Thus one has to add the ability to specify flags that affect the output.
This might be something that packagers should add themselves if they ship a single, pre-packaged, system-wide Boost. (By which I mean, RedHat could add pkgconfig to their boost RPM, because they only ship a single libboost_regex.so, not libboost_regex-gcc-mt-1_32.so and other toolset/build/thread combos). In my opinion that feature must be provided by boost. Imagine suse packaging boost with boost_python-1.32.pc and boost_threads-1.32.pc ... and redhat doing the same but the pkg-config files get named like libboostpython-1.32.pc ... The users of boost would suddenly have the same problem, just on a different level.
Another, related option, is a boost-config script that allows you to specify which libs you want, and which versions, e.g. boost-config thread regex signals --libs might output: -L/usr/lib/ -lboost_regex -lboost_thread -lboost_signals
and boost-config regex --libs --toolset=gcc --build=mt might output: -L/usr/lib/ -lboost_regex-gcc-mt-1_32
A number of projects I know provide a file like this, which is almost as easy to use in autoconf/automake as pkgconfig (there are standard macros for using such a file in place of pkgconfig).
Yes, that makes using boost much simpler. One could also output proper flags for include directories, so packagers could install several versions of boost on one system. Regards Andreas Pokorny
Hi boosters I wrote this (attached file) recently for some my projects which is uses boost (currently only headers and no binary code)... It can be start point to develop autoconf support for boost (which is really needed). Any opinions about how to improve this m4 are welcome ;) On Wednesday 15 December 2004 16:38, Neal D. Becker wrote:
First, I would say, there is a need for a better autoconf for boost. There has been some interest in scons, and scons also includes some capability here that might be useful.
I don't think pkg-config is the right tool. All it is for is to record the settings that were used to build packages - it doesn't figure them out. I don't see how that would help boost.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andreas Pokorny wrote:
Hi Boosters, I am using boost in several projects now, and some of these projects will be released as open source. So they will have a configure script that checks the compiling host, and which should report missing libraries. I saw many open source projects adding boost to their source code tree directly, thus these projects dont have to check the proper boost versions, or library names. That solve the problem, but thats not a fine solution. To simplify using boost libraries i would like to see boost supporting pkg-config or a different maybe better approach which fits better to boost's needs. But first I would like to explain how pkg-config works, and how pkg-config makes using librariers simple.
The pkg-config package can be found here: http://pgk-config.freedesktop.org/wiki/Software_2fpkgconfig
It seems to work on all unix systems and windows. The pkg-config script parses .pc files from several locations in the system, and allows querrying the existance, version, compiler flags and linker flags of installed libraries.
That sounds very similar to Ullrich Koethe's idea as described in http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configuration... (http://tinyurl.com/6dbbl). Is that about right? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
BTW, as requested, I'm crossposting the boost.build in an effort to move the dicussion there. On 12/15/2004 02:12 PM, David Abrahams wrote: [snip]
That sounds very similar to Ullrich Koethe's idea as described in http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configuration... (http://tinyurl.com/6dbbl). Is that about right?
That page contains as a possible example: dependency vigra : /software/vigra-1.1.3/$platform/Jamreport to declare a dependency on a particular version (i.e. 1.1.3) of the vigra library. This could be extended to declare a dependency on just parts of boost. For example, version 1.1.3 of mpl. But, you say, there's no version associated with mpl that's not the same as the boost version. Ah, but during development, several "local" trial versions of mpl may be used. These versions and their associated dependencies could easily be recorded in a *.release.log file like the one mentioned here: http://lists.boost.org/MailArchives/boost/msg76550.php so the above dependency for version 1.1.3 o mpl could be expressed: dependency mpl : boost-root.ln/release/gcc/debug/libs/mpl/test.release.log.~1.1.3~ where, there would be a versioned test.log file with entries as described in */msg76550.php for productions.release.log.
participants (10)
-
Andreas Pokorny -
Caleb Epstein -
David Abrahams -
Jody Hagins -
Jonathan Wakely -
Larry Evans -
Marcelo E. Magallon -
Neal D. Becker -
Stefan Seefeld -
zaufi＠sendmail.ru