Re: [Boost-bugs] [Boost C++ Libraries] #1094: Finding the correct library to link (feature request for pkg-config support)h

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #1094: Finding the correct library to link (feature request for pkg-config support)h
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-12-04 12:56:04


#1094: Finding the correct library to link (feature request for pkg-config
support)h
--------------------------------+-------------------------------------------
  Reporter: rleigh@… | Owner: vladimir_prus
      Type: Feature Requests | Status: assigned
 Milestone: Boost 1.42.0 | Component: build
   Version: | Severity: Problem
Resolution: | Keywords: pkg-config linking library naming
--------------------------------+-------------------------------------------

Comment (by Roger Leigh <rleigh@…>):

 I've been think about how to better support this. I was recently
 introduced to /usr/include/boost/config/auto_link.hpp which supports auto-
 linking on MSVC and Borland compilers. I've been looking at if this would
 also be a suitable mechanism for getting the information for generating
 pkg-config .pc files for a boost build.

 If we have a simple program that includes each Boost header, e.g. for
 boost_filesystem:

 #define BOOST_PKG_CONFIG_DUMP_LIBS

 #include <boost/filesystem.hpp>
 int main()
 {
   const char *libs = BOOST_PKG_CONFIG_LIBS;
 }

 and auto_link.hpp defined BOOST_PKG_CONFIG_LIBS if
 BOOST_PKG_CONFIG_DUMP_LIBS was set

 we can write a simple C++ program that's compiled with a range of headers
 and can then print out the .pc file to stdout. This will ensure
 consistent linking across platforms.

 I've been looking at doing this, but the main sticking point is the C
 preprocessor. A single include can cause auto_link.hpp to be included
 multiple times, and the C preprocessor doesn't allow TTBOMK modification
 of existing macros to allow appending of a value or concatenation so we
 can store a list of libs across includes. If there was some way of
 transparently getting the information out, this would be ideal. The
 existing compilers don't need to deal with this because they all use
 #pragmas, whereas we can't do that AFAICT.

 Maybe the Boost preprocessor macros can help here, but this is outside my
 current experience. Any ideas?


 Regards,
 Roger

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/1094#comment:18>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:05 UTC