[boost.build] RFE: pkg-config
Hi there, many moons ago we had a discussion about how to tell users about build flags necessary to build software that uses boost libraries. Was there any consensus about how to do that ? Let me briefly resume the problem I'm facing. I'm writing software that uses boost libraries (boost.python, boost.wave, etc.). I'v been working with current snapshots, which provide libraries such as libboost_python-gcc-mt-1_33.so. However, I can't hardcode that name into my build scripts, as at some point after boost 1.33 gets officially released, I may take a boost package provided by the OS distributor I'm using. Chances are high that the boost libraries will be named differently then, i.e. instead of libboost_python-gcc-mt-1_33.so I will get 'libboost_python.so'. There are many more issues, which we already discussed in detail (library dependencies, required compilation flags, etc., etc.). The real problem is that this situation requires some cooperation between boost developers and boost packagers, or else the burden of figuring out all these details falls on the user. Thus I think it would be great for boost to provide some kind of table that users can inspect to figure out all the metainfo about the libraries they need. This table would be created in a transparent way that encourages packagers to recreate it to reflect the way they package boost. As I'm working mostly with unix, a natural candidate for such a table is 'pkg-config' (an option that was suggested before), but I can see some developers not wanting to use any specific tool. An alternative would be to develop a boost-specific tool that then becomes part of every boost package, and which users can query such as 'which additional libraries do I need to link with when using library 'XYZ' ?' etc. However, that tool should be neutral, i.e. while it should be able to provide all the data required to build software with boost, it must not assume any particular build system (make, bjam, scons, whatever). Is there any work done in this direction ? Thanks, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Hi there,
many moons ago we had a discussion about how to tell users about build flags necessary to build software that uses boost libraries. Was there any consensus about how to do that ?
Best way: write a little Boost.Build project that uses the bits you need, and do a bjam -n -a to see the command-lines.
Let me briefly resume the problem I'm facing. I'm writing software that uses boost libraries (boost.python, boost.wave, etc.). I'v been working with current snapshots, which provide libraries such as libboost_python-gcc-mt-1_33.so. However, I can't hardcode that name into my build scripts, as at some point after boost 1.33 gets officially released, I may take a boost package provided by the OS distributor I'm using. Chances are high that the boost libraries will be named differently then, i.e. instead of libboost_python-gcc-mt-1_33.so I will get 'libboost_python.so'. There are many more issues, which we already discussed in detail (library dependencies, required compilation flags, etc., etc.).
The real problem is that this situation requires some cooperation between boost developers and boost packagers, or else the burden of figuring out all these details falls on the user.
Thus I think it would be great for boost to provide some kind of table that users can inspect to figure out all the metainfo about the libraries they need. This table would be created in a transparent way that encourages packagers to recreate it to reflect the way they package boost.
The right thing to do is generate a (BBv2) Jamfile that creates targets for the prebuilt libraries and correctly specifies their usage-requirements.
As I'm working mostly with unix, a natural candidate for such a table is 'pkg-config' (an option that was suggested before), but I can see some developers not wanting to use any specific tool.
An alternative would be to develop a boost-specific tool that then becomes part of every boost package, and which users can query such as 'which additional libraries do I need to link with when using library 'XYZ' ?' etc.
The problem with adding another tool is that information can all be generated by the build system for dependent projects. Trying to replicate that capability externally and keep the two in synch would be a nightmare. That's why this should be done with the build tool. On the other hand, I'm not opposed to using a front-end atop Boost.Build for this purpose. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
The problem with adding another tool is that information can all be generated by the build system for dependent projects. Trying to replicate that capability externally and keep the two in synch would be a nightmare. That's why this should be done with the build tool. On the other hand, I'm not opposed to using a front-end atop Boost.Build for this purpose.
I agree that duplicating the data manually would be a maintenance nightmare. On the other hand, I don't think users of boost libraries should be required to know about bjam either. What I imagine is some 'database' (m4 file for autoconf, pkg-config file, whatever) that is *generated* by bjam as part of the build process. Unix developers are quite used to the idea: tools such as pkg-config work exactly like that. Appropriate files are generated during configuration / installation, and can be further tuned during the packaging, if necessary. Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way. Regards, Stefan
Stefan Seefeld wrote:
David Abrahams wrote:
The problem with adding another tool is that information can all be generated by the build system for dependent projects. Trying to replicate that capability externally and keep the two in synch would be a nightmare. That's why this should be done with the build tool. On the other hand, I'm not opposed to using a front-end atop Boost.Build for this purpose.
I agree that duplicating the data manually would be a maintenance nightmare. On the other hand, I don't think users of boost libraries should be required to know about bjam either. What I imagine is some 'database' (m4 file for autoconf, pkg-config file, whatever) that is *generated* by bjam as part of the build process.
That's possible, I think.
Unix developers are quite used to the idea: tools such as pkg-config work exactly like that. Appropriate files are generated during configuration / installation, and can be further tuned during the packaging, if necessary.
Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way.
If this is done by Boost.Build, it's required the all packages use Boost.Build too. If they build boost in some other way, then there's nothing we can do. Looking at 'man pkgconfig' I see the the .pc file are required to contain only linker flags and compiler flags. I think that information can be easily generated by Boost.Build V2 -- because the only variable part is the installation location and the name of the library. Actually, why don't just provide static .pc files? On Unix, gcc is the standard compiler, so libboost_filesystem_gcc.so should work ;-) - Volodya
Vladimir Prus wrote:
Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way.
If this is done by Boost.Build, it's required the all packages use Boost.Build too. If they build boost in some other way, then there's nothing we can do.
Indeed. The point is really to make it *possible* for them to do it without boost developers having to care. If packagers build boost with bjam, but then rename libraries manually, they need to manually adjust the table. Still the whole process is transparent to users, as they would still look up library names in the same table.
Looking at 'man pkgconfig' I see the the .pc file are required to contain only linker flags and compiler flags. I think that information can be easily generated by Boost.Build V2 -- because the only variable part is the installation location and the name of the library.
Actually, why don't just provide static .pc files? On Unix, gcc is the standard compiler, so libboost_filesystem_gcc.so should work ;-)
:-) Let's take a concrete example: I want to use boost.wave, so I'm looking for a 'boost_wave.pc' file. `pkgconfig --libs boost_wave` should report something like '-lboost_wave -lboost_program_options -lboost_filesystem' on my FC box, but when using boost from CVS installed in /usr/local, the same command may report: '-L/usr/local/lib -lboost_wave-gcc-1_33 -lboost_program_options-gcc-1_33 -lboost_filesystem-gcc-1_33' You get the idea... Thanks, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
Vladimir Prus wrote:
Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way.
If this is done by Boost.Build, it's required the all packages use Boost.Build too. If they build boost in some other way, then there's nothing we can do.
Indeed. The point is really to make it *possible* for them to do it without boost developers having to care.
I don't understand. What is "it" and what does it mean to "care" in this case? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
Vladimir Prus wrote:
Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way.
If this is done by Boost.Build, it's required the all packages use Boost.Build too. If they build boost in some other way, then there's nothing we can do.
Indeed. The point is really to make it *possible* for them to do it without boost developers having to care.
I don't understand. What is "it" and what does it mean to "care" in this case?
'it' is the regeneration / manipulation of the file containing library metainformation such as required build flags or dependencies. 'not having to care' means that boost developers can completely ignore the issue of packaging as packagers have all the tools they need to keep the installed files self-consistent. Regards, Stefan
Stefan Seefeld wrote:
Vladimir Prus wrote:
Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way.
If this is done by Boost.Build, it's required the all packages use Boost.Build too. If they build boost in some other way, then there's nothing we can do.
Indeed. The point is really to make it *possible* for them to do it without boost developers having to care. If packagers build boost with bjam, but then rename libraries manually, they need to manually adjust the table. Still the whole process is transparent to users, as they would still look up library names in the same table.
I think that if packagers rename the libraries.... well nothing would work because then the name of the library encoded inside it will be different from the filename ;-) So, packages will either 1. Build boost in some other way 2. Make Boost.Build use the conventions they want. In either case, they'll know the naming conventions used and can generate .pc files without any Boost.Build help. Boost.Build support is only desired if packages will be created by "bjam --some-naming-convention", it which case packages won't have to do anything. It's also desired for those building from CVS and installing boost manually, bypassing package management system. Do we agree on the above?
Let's take a concrete example:
I want to use boost.wave, so I'm looking for a 'boost_wave.pc' file.
`pkgconfig --libs boost_wave`
should report something like '-lboost_wave -lboost_program_options -lboost_filesystem' on my FC box,
I think Boost packages for all Linux distribution will have exactly those names, so static .pc file can be fine.
but when using boost from CVS installed in /usr/local, the same command may report:
'-L/usr/local/lib -lboost_wave-gcc-1_33 -lboost_program_options-gcc-1_33 -lboost_filesystem-gcc-1_33'
You get the idea...
Ok, for installing from CVS the name indeed can vary. Note however, that for shared linking you don't need -l...program_options... and -l...filesystem... at all. BTW, where should .pc file be installed? $prefix/lib/pkgconfig or /usr/lib/pkgconfig? With arbitrary prefix, the .pc file just won't be found, which make it useless. - Volodya
Vladimir Prus wrote:
I think that if packagers rename the libraries.... well nothing would work because then the name of the library encoded inside it will be different from the filename ;-)
You are right, on most systems there is more to renaming a library than just 'mv foo.so bar.so'.
So, packages will either 1. Build boost in some other way 2. Make Boost.Build use the conventions they want.
In either case, they'll know the naming conventions used and can generate .pc files without any Boost.Build help.
Sure they *can*. But so far it hasn't happened, and I believe instead of sending a RFE to RedHat and Debian and... it is simpler to make the change to the boost build system and then encourage packagers to follow the example.
Boost.Build support is only desired if packages will be created by "bjam --some-naming-convention", it which case packages won't have to do anything. It's also desired for those building from CVS and installing boost manually, bypassing package management system.
Do we agree on the above?
Yes.
Let's take a concrete example:
I want to use boost.wave, so I'm looking for a 'boost_wave.pc' file.
`pkgconfig --libs boost_wave`
should report something like '-lboost_wave -lboost_program_options -lboost_filesystem' on my FC box,
I think Boost packages for all Linux distribution will have exactly those names, so static .pc file can be fine.
Ok. But who creates / maintains them ?
but when using boost from CVS installed in /usr/local, the same command may report:
'-L/usr/local/lib -lboost_wave-gcc-1_33 -lboost_program_options-gcc-1_33 -lboost_filesystem-gcc-1_33'
You get the idea...
Ok, for installing from CVS the name indeed can vary. Note however, that for shared linking you don't need -l...program_options... and -l...filesystem... at all.
That depends on the platform. Not everywhere is the dependency encoded in the library itself. On some the user has to explicitly (re)link with *all* libraries.
BTW, where should .pc file be installed? $prefix/lib/pkgconfig or /usr/lib/pkgconfig? With arbitrary prefix, the .pc file just won't be found, which make it useless.
I install them into <prefix>/lib/pkgconfig. That of course requires the PKG_CONFIG_PATH to be set. That is basically the same procedure as setting the LD_LIBRARY_PATH if libraries are installed in places not automatically looked in by the library loader. Regards, Stefan
On Thu, Jun 16, 2005 at 07:59:49AM -0400, Stefan Seefeld wrote:
Vladimir Prus wrote:
I think that if packagers rename the libraries.... well nothing would work because then the name of the library encoded inside it will be different from the filename ;-)
You are right, on most systems there is more to renaming a library than just 'mv foo.so bar.so'.
So, packages will either 1. Build boost in some other way 2. Make Boost.Build use the conventions they want.
In either case, they'll know the naming conventions used and can generate .pc files without any Boost.Build help.
Sure they *can*. But so far it hasn't happened, and I believe instead of sending a RFE to RedHat and Debian and... it is simpler to make the change to the boost build system and then encourage packagers to follow the example.
And if only pre-built packaged versions come with pkg-config support it doesn't help if I want to switch between the pre-built libs and ones I built myself from CVS.
BTW, where should .pc file be installed? $prefix/lib/pkgconfig or /usr/lib/pkgconfig? With arbitrary prefix, the .pc file just won't be found, which make it useless.
I install them into <prefix>/lib/pkgconfig. That of course requires the PKG_CONFIG_PATH to be set. That is basically the same procedure as setting the LD_LIBRARY_PATH if libraries are installed in places not automatically looked in by the library loader.
And IMHO that's an important point, just by using a different PKG_CONFIG_PATH you can link to a completely different set of libs: make PKG_CONFIG_PATH=$HOME/my_local_version_of_boost or make CXX=g++41 PKG_CONFIG_PATH=$HOME/boost_built_with_gcc41 I wouldn't have to change the Makefile at all for this to work. jon
Jonathan Wakely wrote:
I install them into <prefix>/lib/pkgconfig. That of course requires the PKG_CONFIG_PATH to be set. That is basically the same procedure as setting the LD_LIBRARY_PATH if libraries are installed in places not automatically looked in by the library loader.
And IMHO that's an important point, just by using a different PKG_CONFIG_PATH you can link to a completely different set of libs:
make PKG_CONFIG_PATH=$HOME/my_local_version_of_boost or make CXX=g++41 PKG_CONFIG_PATH=$HOME/boost_built_with_gcc41
I wouldn't have to change the Makefile at all for this to work.
Pretty cool, I'd say. And, BTW, does pkg-config have any documentation besides extra lean man page? I could not find any. - Volodya
On Fri, Jun 17, 2005 at 06:26:56PM +0400, Vladimir Prus wrote:
Jonathan Wakely wrote:
I install them into <prefix>/lib/pkgconfig. That of course requires the PKG_CONFIG_PATH to be set. That is basically the same procedure as setting the LD_LIBRARY_PATH if libraries are installed in places not automatically looked in by the library loader.
And IMHO that's an important point, just by using a different PKG_CONFIG_PATH you can link to a completely different set of libs:
make PKG_CONFIG_PATH=$HOME/my_local_version_of_boost or make CXX=g++41 PKG_CONFIG_PATH=$HOME/boost_built_with_gcc41
I wouldn't have to change the Makefile at all for this to work.
Pretty cool, I'd say. And, BTW, does pkg-config have any documentation besides extra lean man page? I could not find any.
It's on www.freedesktop.org IIRC ... yes: http://freedesktop.org/wiki/Software_2fpkgconfig jon
On Fri, Jun 17, 2005 at 04:23:52PM +0100, Jonathan Wakely wrote:
On Fri, Jun 17, 2005 at 06:26:56PM +0400, Vladimir Prus wrote:
Pretty cool, I'd say. And, BTW, does pkg-config have any documentation besides extra lean man page? I could not find any.
It's on www.freedesktop.org IIRC ... yes:
Ha! I should have checked before posting, it just says "see the man page" :) jon
Stefan Seefeld wrote:
Let's take a concrete example:
I want to use boost.wave, so I'm looking for a 'boost_wave.pc' file.
`pkgconfig --libs boost_wave`
should report something like '-lboost_wave -lboost_program_options -lboost_filesystem' on my FC box,
I think Boost packages for all Linux distribution will have exactly those names, so static .pc file can be fine.
Ok. But who creates / maintains them ?
Hmm... I guess asking all packagers to create their own version is not good.
Ok, for installing from CVS the name indeed can vary. Note however, that for shared linking you don't need -l...program_options... and -l...filesystem... at all.
That depends on the platform. Not everywhere is the dependency encoded in the library itself. On some the user has to explicitly (re)link with *all* libraries.
Namely? (Static linking is another issues, of course).
BTW, where should .pc file be installed? $prefix/lib/pkgconfig or /usr/lib/pkgconfig? With arbitrary prefix, the .pc file just won't be found, which make it useless.
I install them into <prefix>/lib/pkgconfig. That of course requires the PKG_CONFIG_PATH to be set. That is basically the same procedure as setting the LD_LIBRARY_PATH if libraries are installed in places not automatically looked in by the library loader.
Ok. - Volodya
Vladimir Prus wrote:
I think Boost packages for all Linux distribution will have exactly those names, so static .pc file can be fine.
Ok. But who creates / maintains them ?
Hmm... I guess asking all packagers to create their own version is not good.
Right. I think I wasn't very clear: I believe generating and installing pc files for all boost libraries as part of the boost.build process is fine. Yet some systems package the libraries differently (renamed libraries, different installation prefixes, etc.), so it must be possible to modify those files.
Ok, for installing from CVS the name indeed can vary. Note however, that for shared linking you don't need -l...program_options... and -l...filesystem... at all.
That depends on the platform. Not everywhere is the dependency encoded in the library itself. On some the user has to explicitly (re)link with *all* libraries.
Namely?
Sorry, can't find any offhand. But I had the problem in the past where I had to explicitely link with libraries I only depended on indirectly. Unfortunately building / linking / loading shared libraries is a pretty ugly aspect of most OSes, which is why tools such as pkg-config and libtool exist in the first place. Regards, Stefan
On 6/17/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Right. I think I wasn't very clear: I believe generating and installing pc files for all boost libraries as part of the boost.build process is fine. Yet some systems package the libraries differently (renamed libraries, different installation prefixes, etc.), so it must be possible to modify those files.
If the vendors install things "the right way" (e.g. using bjam, and possibly using the lightly documented --layout flag -- see BOOST_ROOT/Jamfile), then bjam ought to be able to generate the .pc files with the correct settings. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On 6/17/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Right. I think I wasn't very clear: I believe generating and installing pc files for all boost libraries as part of the boost.build process is fine. Yet some systems package the libraries differently (renamed libraries, different installation prefixes, etc.), so it must be possible to modify those files.
If the vendors install things "the right way" (e.g. using bjam, and possibly using the lightly documented --layout flag -- see BOOST_ROOT/Jamfile), then bjam ought to be able to generate the .pc files with the correct settings.
I didn't know bjam supports packaging a la rpm, deb, etc. FWIW, everybody has his own idea about what 'the right way' is, and imposing only a single possible way seems to me a bit narrow minded and unrealistic in this context. FWIW. Regards, Stefan
On 6/17/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Caleb Epstein wrote:
On 6/17/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Right. I think I wasn't very clear: I believe generating and installing pc files for all boost libraries as part of the boost.build process is fine. Yet some systems package the libraries differently (renamed libraries, different installation prefixes, etc.), so it must be possible to modify those files.
If the vendors install things "the right way" (e.g. using bjam, and possibly using the lightly documented --layout flag -- see BOOST_ROOT/Jamfile), then bjam ought to be able to generate the .pc files with the correct settings.
I didn't know bjam supports packaging a la rpm, deb, etc. FWIW, everybody has his own idea about what 'the right way' is, and imposing only a single possible way seems to me a bit narrow minded and unrealistic in this context. FWIW.
Ok, there is surely more than one "right way", but I was just suggesting that a vendor can build a system-specific package (rpm, deb, etc) from the boost sources without needing to bang on the build system very much. "bjam --layout=system --prefix=tmp/usr install" or thereabouts. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
Ok, there is surely more than one "right way", but I was just suggesting that a vendor can build a system-specific package (rpm, deb, etc) from the boost sources without needing to bang on the build system very much. "bjam --layout=system --prefix=tmp/usr install" or thereabouts.
And that's exactly what the --layout=system option was meant to do. It wasn't meant as a substitute for packaging. And was design with feedback from the Boost RedHat package maintainer. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Caleb Epstein wrote:
Ok, there is surely more than one "right way", but I was just suggesting that a vendor can build a system-specific package (rpm, deb, etc) from the boost sources without needing to bang on the build system very much. "bjam --layout=system --prefix=tmp/usr install" or thereabouts.
And that's exactly what the --layout=system option was meant to do. It wasn't meant as a substitute for packaging. And was design with feedback from the Boost RedHat package maintainer.
Excellent ! I hope every potential packager will be aware of the option for it to be most useful. The documentation should have a page specifically addressed at potential packagers that discusses the required steps. Regards, Stefan
On Tue, 2005-06-14 at 12:34 -0400, Stefan Seefeld wrote:
David Abrahams wrote:
The problem with adding another tool is that information can all be generated by the build system for dependent projects. Trying to replicate that capability externally and keep the two in synch would be a nightmare. That's why this should be done with the build tool. On the other hand, I'm not opposed to using a front-end atop Boost.Build for this purpose.
I agree that duplicating the data manually would be a maintenance nightmare. On the other hand, I don't think users of boost libraries should be required to know about bjam either. What I imagine is some 'database' (m4 file for autoconf, pkg-config file, whatever) that is *generated* by bjam as part of the build process.
Unix developers are quite used to the idea: tools such as pkg-config work exactly like that. Appropriate files are generated during configuration / installation, and can be further tuned during the packaging, if necessary.
Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way.
I agree with you. Linking against Boost is difficult; I've had to fight this problem in the past as I'm the package maintainer of Boost under NetBSD (in fact, under pkgsrc, a portable packaging system). The untypical names in the library names make this task very complex (and very error prone). It seemed to me that building with --layout=system was the solution, because then I'd simply rename the libraries to libboost_whatever.so and the linking became trivial (-lboost_whatever) from any project that needed Boost: no need to know which toolset was used, which features were enabled (e.g., multithread), etc. Unfortunately, I just learned that this is incorrect, mostly because the libraries were built under NetBSD without soname support (due to a problem in the .jam files, not my fault ;). So... I've been using the following m4 code in my configure scripts to look for Boost: ---- snip ---- AC_ARG_VAR(BOOST_SUFFIX, [String suffix that identifies Boost libraries (empty by default)]) AC_DEFUN([BOOST_CHECK], [AC_CHECK_HEADERS($2, , AC_MSG_FAILURE([cannot find Boost.$1 headers])) m4_if($#, 3, [ found=no suffixes=${BOOST_SUFFIX:-"none -gcc -mipspro -mt -sunpro"} for BOOST_SUFFIX in ${suffixes} do test ${BOOST_SUFFIX} = none && BOOST_SUFFIX= libname="$3[${BOOST_SUFFIX}]" AC_MSG_CHECKING(for -l${libname}) old_libs="${LIBS}" LIBS="-l${libname} ${LIBS}" AC_LINK_IFELSE([int main(void) { return 0; }], found=yes) LIBS="${old_libs}" AC_MSG_RESULT(${found}) test ${found} = yes && break done if test ${found} = no; then AC_MSG_FAILURE([cannot find the Boost $1 library]) fi]) ]) ---- snip ---- And as an example, to detect some required libraries: ---- snip ---- BOOST_CHECK([Format], [boost/format.hpp]) BOOST_CHECK([Smart Pointers], [boost/shared_ptr.hpp]) BOOST_CHECK([Utility], [boost/noncopyable.hpp]) BOOST_CHECK([Filesystem], [boost/filesystem/convenience.hpp \ boost/filesystem/fstream.hpp \ boost/filesystem/operations.hpp \ boost/filesystem/path.hpp], [boost_filesystem]) ---- snip ---- Note that this is very far from simple, and many times it requires help from the user to find them (i.e., setting BOOST_SUFFIX) :-( Having .pc files could be indeed nice; just do something like 'pkg-config --libs boost_filesystem' and forget! I'm sure these could be "easily" generated on the fly by Boost.Build to minimize maintenance problems. Also nice could be to have a --layout=system feature that used names that were completely system-agnostic (currently, I'm getting '-mt' embedded into them, although it shouldn't be there, IMHO). Cheers, -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
participants (7)
-
Caleb Epstein -
David Abrahams -
Jonathan Wakely -
Julio M. Merino Vidal -
Rene Rivera -
Stefan Seefeld -
Vladimir Prus