Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-10-28 17:03:29


Ingmar Vanhassel wrote:

> Excerpts from troy d. straszheim's message of Wed Oct 28 21:23:26 +0100 2009:
>> Ingmar Vanhassel wrote:
>> > Excerpts from Sean Chittenden's message of Wed Oct 28 21:08:19 +0100 2009:
>> >>>> Avoid pkg-config, it's very Linux and drags in a ton of dependencies
>> >>>> (most of the time, never required, but that's the way it goes with
>> >>>> everyone's packaging system of choice). A cmake variable would be
>> >>>> preferred, imo (similar to the cmake boost version foo). -sc
>> >>> So let's make pkg-config opt-in?
>> >> Totally, pkg-config is useful goodness. Use it if it's there, but not
>> >> make it the primary or only way.
>> >>
>> >>> What ton of dependencies are you referring to?
>> >> At a minimum it currently requires the following to build (and their
>> >> subsequent dependencies):
>> >>
>> >> gettext-0.17_1 gmake-3.81_3 libiconv-1.13.1
>> >
>> > I'm fairly sure you can --disable-nls to get rid of gettext & libiconv.
>> >
>> >>> How's it linuxy? Do you mean that it's not convenient on non-unix?
>> >> pkgconfig has a tendency to suck in other gnome projects due to its
>> >> gnome lineage. Ugh.
>> >
>> > If you're referring to its limited use of glib, you can disable this
>> > too, and it'll use an embedded copy of the few things it uses from glib.
>> > Not ideal, but workable.
>> >
>> >>> pkg-config is quite useful on linux distributions. I largely prefer
>> >>> using
>> >>> pkg-config over going back to having a gazillion foo-config binaries.
>> >> I get the value of pkg-config, not arguing against it, just pointing
>> >> out that we have the necessary tools in place with cmake and that
>> >> cmake is well suited for solving this problem without adding
>> >> additional dependencies. :)
>> >
>> > Okay, then we don't really disagree. :-)
>> >
>>
>> So none of these dependencies apply to us generating the file (s)
>> necessary for pkg-config, right? I'd assumed this would be as easy as
>> generating the file (with configure_file) and installing it to the right
>> place. Could somebody post a template config file and instructions on
>> where to install it?
>
> You don't need pkg-config at all to generate a pkg-config file, you need
> it to use the file, ie when building packages that want to find boost
> via pkg-config
>
> Something like this would generate boost.pc from boost.pc.cmake when
> building boost. (Note: From memory, I'm not looking at boost-cmake.git
> atm)
>
> CMakeLists.txt:
> ---
> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/boost.pc.cmake
> ${CMAKE_CURRENT_BINARY_DIR}/boost.pc
> @ONLY)
> install(FILES ${CMAKE_CURRENT_BINARY_DIR}/boost.pc
> DESTINATION ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}/pkgconfig)
> ---
>
> then a boost.pc.cmake:
> ---
> prefix=@CMAKE_INSTALL_PREFIX@
> exec_prefix=@CMAKE_INSTALL_PREFIX@
> libdir=@CMAKE_INSTALL_PREFIX@/lib_at_LIB_SUFFIX@
> includedir=@CMAKE_INSTALL_PREFIX@/include/boost
>
> Name: Boost
> Description: Description about Boost
> Version: @BOOST_VERSION@
> Libs:
> Cflags:
> ----
>
> Or maybe one .pc file per library. Not sure

One .pc per library will surely be better -- as it won't require neither
linking to all .so files nor creating one 'meta' boost.so library. However,
IIUC, if we have multiple .pc files, then we'll have multiple

        -I @CMAKE_INSTALL_PREFIX@/include/boost

options if a project uses more than one .pc file. Is there a way to
workaround this?

- Volodya

>


Boost-cmake list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk