On Tue, Mar 01, 2011 at 02:41:04PM +0300, Vladimir Prus wrote:
> On Tuesday, March 01, 2011 14:21:54 Roger Leigh wrote:
> > For the patch I mentioned in my initial mail, this just needs building
> > and running in a loop, such as (pseudocode)
> >
> > for (header+library name in each of boost's libraries) {
> > compile with PREFIX=prefix LIBDIR=libdir TEST_HEADER=header
> > TEST_LIBRARY=library link with all boost libraries
> > run to autogenerate header > library.pc (e.g. boost_program_options.pc)
> > }
>
> As you've mentioned yourself, this approach won't work very well for
> cross-compilation.
>
> Also -- we still get the question from the original issue -- what shall we do
> if building multiple variants together with decorated names? Use the same
> decoration for .pc files as we do for library files?If you're building multiple variants, you would need multiple .pc files, one per library variant. The same decoration would be appropriate so they match. At least on Linux, where we only really usually care about a single release variant, and use it undecorated, it would be nice to have a set of undecorated files so that you can just use e.g. `pkg-config --libs boost_program_options` and get the system default. If the user needs a specific variant, they could use a more specific suffix. These undecorated variants could be either generated by boost, or be a set of symlinks to specific variants created by the distributor (who would choose the default). Steve is better qualified to comments on the requirements here ;) In practice, on Linux there is only one variant (two if you include debugging symbols), so we don't really need (or want) to consider the non-standard naming conventions used by Boost. We have a system default toolchain, so variants are redundant; Boost is the only project creating such non-standard suffixes. It's fine to create those extra .pc files for the multiple variants, but in practice I doubt they will be used. In my projects, I'll be using autoconf like this: PKG_CHECK_MODULES([BOOST_PROGRAM_OPTIONS], [boost_program_options]) and have it autodetect the system defaults. The other variants won't be considered. This will cause BOOST_PROGRAM_OPTIONS_LIBS to be set to "-lboost_program_options", and would include dependent libs in the case of e.g. boost_filesystem. This is the typical use case for pkg-config files. If there's a use case for pkg-config on Windows, I'm sure the variants will have a use there. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
