Re: [Boost-cmake] CMAKE_CXX_FLAGS on Darwin...

Adding the ${CMAKE_CXX_FLAGS} to ADD_DEFINITIONS() seems redundant.to me because CMAKE_CXX_FLAGS already sets definitions passed to the c++ compiler. I think this flag is more useful for setting config-dependent flags, e.g. CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE, but maybe others on the

Re: [Boost-cmake] RFC: exported targets

Ingmar Vanhassel wrote: Excerpts from troy d. straszheim's message of Thu Oct 29 23:18:12 +0100 2009: I haven't forgotten about LIB_SUFFIX. It is footnoted in the exported targets section of the docs: I meant the cmake/ subdirectory, to avoid cluttering the library directory with .cmake files

[Boost-cmake] CMAKE_CXX_FLAGS on Darwin...

I've been running with the following snippet in my boost build directory for a while. IF(CMAKE_COMPILER_IS_GNUCXX) IF(APPLE) ADD_DEFINITIONS(${CMAKE_CXX_FLAGS} "-gdwarf-2") ENDIF(APPLE) # At some point in the future, this won't be requied to silence an # error message for boost, b

Re: [Boost-cmake] RFC: exported targets

Excerpts from troy d. straszheim's message of Thu Oct 29 23:18:12 +0100 2009: > Ingmar Vanhassel wrote: > > Excerpts from troy d. straszheim's message of Thu Oct 29 21:03:01 +0100 > > 2009: > >> Brad King wrote: > >>> troy d. straszheim wrote: > Michael Jackson wrote: > > This is THE SING

Re: [Boost-cmake] RFC: exported targets

Ingmar Vanhassel wrote: Excerpts from troy d. straszheim's message of Thu Oct 29 21:03:01 +0100 2009: Brad King wrote: troy d. straszheim wrote: Michael Jackson wrote: This is THE SINGLE IMPROVEMENT someone could make for those of us using CMake and are dependent on the boost libraries. I di

Re: [Boost-cmake] RFC sonames initial implementation

Brad King wrote: If there is no interface version, there is no need for the soname to be different from the real binary name. IOW, we could just set VERSION=1.2 and no SOVERSION, and CMake will produce libfoo.so -> libfoo.so.1.2 # link to help static linker -lfoo flags libfoo.so.1.2

Re: [Boost-cmake] RFC: exported targets

troy d. straszheim wrote: > if you link to > boost_threads-mt-shared, for instance, with the installed exports you > automagically get -pthread and friends, but with the noninstalled > exports you don't. Is this expected? It should work for both. Make sure that the export() command for a target

Re: [Boost-cmake] RFC: exported targets

Ingmar Vanhassel wrote: >> Yes. This is a great cmake feature. Boost.CMake now uses this to >> install a $PREFIX/lib/Boost.cmake file. > > Can we agree on $PREFIX/lib$LIB_SUFFIX/cmake/Boost.cmake please? > > Also, some users may want to install multiple versions of boost, so I'd > shove $BOOST_

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Right now there's no version info on the .so's. Going forward with .so version info that's unique, it won't. :) -sc -- Sean Chittenden On Oct 29, 2009, at 12:51 PM, Vladimir Prus wrote: Sean Chittenden wrote: /usr local lib boost-1.40.0 boost-1.41.0 boost -> boost-

Re: [Boost-cmake] RFC: exported targets

Excerpts from Ingmar Vanhassel's message of Thu Oct 29 21:11:16 +0100 2009: > Also, some users may want to install multiple versions of boost, so I'd > shove $BOOST_VERSION in the filename too. On that note, it would be a good help if our includes were installed in a versioned directory. -- Exhe

Re: [Boost-cmake] RFC: exported targets

Excerpts from troy d. straszheim's message of Thu Oct 29 21:03:01 +0100 2009: > Brad King wrote: > > troy d. straszheim wrote: > >> Michael Jackson wrote: > >>> This is THE SINGLE IMPROVEMENT someone could make for those of us > >>> using CMake and are dependent on the boost libraries. > >> I did s

Re: [Boost-cmake] RFC: exported targets

Brad King wrote: troy d. straszheim wrote: Michael Jackson wrote: This is THE SINGLE IMPROVEMENT someone could make for those of us using CMake and are dependent on the boost libraries. I did some work on this. CMake exported targets are really cool. This doesn't solve the entire FindBoost.c

Re: [Boost-cmake] RFC: exported targets

troy d. straszheim wrote: > Michael Jackson wrote: >> This is THE SINGLE IMPROVEMENT someone could make for those of us >> using CMake and are dependent on the boost libraries. > > I did some work on this. CMake exported targets are really cool. This > doesn't solve the entire FindBoost.cmake pr

Re: [Boost-cmake] FindBoost.cmake

troy d. straszheim wrote: > Currently we work with cmake back to 2.6.4, I'd like to do something > that works independently of cmake's Modules/FindBoost.cmake (I'm frankly > afraid to even look inside that file). CMake will prefer that file > unless NO_MODULE is specified, so for users of cmake th

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Sean Chittenden wrote: >>> /usr >>> local >>> lib >>> boost-1.40.0 >>> boost-1.41.0 >>> boost -> boost-1.41.0 >>> >>> Lazy developers will use boost and not boost-1.40.0 and suddenly >>> things will break in strange, hard to figure out ways. >> >> Could you clarify what wil

Re: [Boost-cmake] RFC sonames initial implementation

troy d. straszheim wrote: > Is there some standard buildtime toggle for this, or is > BUILD_SOVERSIONED okay? There is no standard AFAIK. > The option is avaiable on UNIX only. Note that setting VERSION does set the windows "image version" in DLLs, but it does not affect the file name. > The im

[Boost-cmake] FindBoost.cmake

Michael Jackson wrote: So the problem I see with this is that I still need to know "a priori" what boost libraries are available on the system so exporting the targets really doesn't help much, at least not me. In your example (quoted below) what happens if I don't have the shared-debug of bo

[Boost-cmake] RFC sonames initial implementation

Brad King wrote: Denis Arnaud wrote: 2009/10/28 Vladimir Prus mailto:vladi...@codesourcery.com>> This might be obvious, but such a soname would be wrong if the above naming of libraries is used, since there would be no libboost_date_time-mt.so.4. - Volodya I've just check

[Boost-cmake] RFC: exported targets

So the problem I see with this is that I still need to know "a priori" what boost libraries are available on the system so exporting the targets really doesn't help much, at least not me. In your example (quoted below) what happens if I don't have the shared- debug of boost-thread but instead

[Boost-cmake] RFC: exported targets

Michael Jackson wrote: This is THE SINGLE IMPROVEMENT someone could make for those of us using CMake and are dependent on the boost libraries. I did some work on this. CMake exported targets are really cool. This doesn't solve the entire FindBoost.cmake problem, but it is easy. http://sodi

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/29 Sean Chittenden > I'm still coming up to speed on boost's convention for micro versions, but > couldn't the SONAME be set to "*.so.1.41" instead of "*.1.41.0" ? > > -sc > That makes a lot of sense (at least to me), of course. But, as Volodya suggests, there is no guarantee that "ups

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Boost has no separate interface and implementation versions, so it may be best to just set the VERSION property on all libraries and no SOVERSION (or vice-versa...each defaults to the other). Then CMake will only create libboost.so -> libboost.so.1.41.0 libboost.so.1.41.0 and the SONAME

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis Arnaud wrote: > > 2009/10/28 Vladimir Prus > > > This might be obvious, but such a soname would be wrong if the above > naming > of libraries is used, since there would be no > libboost_date_time-mt.so.4. > > - Volodya > > > I've jus

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

/usr local lib boost-1.40.0 boost-1.41.0 boost -> boost-1.41.0 Lazy developers will use boost and not boost-1.40.0 and suddenly things will break in strange, hard to figure out ways. Could you clarify what will break? The usual suspects for dynamic linker issues. It's

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/28 Vladimir Prus > This might be obvious, but such a soname would be wrong if the above naming > of libraries is used, since there would be no libboost_date_time-mt.so.4. > > - Volodya > I've just checked what Debianers do. Currently, they set the soname to match the full library name (w

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

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 >> (m

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Denis Arnaud wrote: > 2009/10/28 troy d. straszheim > >> Would it be possible to have the option, with CMake build, to use a >>>more conventional soname, so that Linux distribution packagers >>>(Debianers and RPM-based packagers such as me, for instance) be >>>happy (i.e., have l

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

Sean Chittenden wrote: >> For sure it is. Debian is my primary platform and I'd like this to >> be seamless. I've pondered support for multiple simultaneous >> installations, possibly with a layout like this: > > Because of the trickery of the loader using unresolved symlinks (for > non-statica

Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix

2009/10/28 troy d. straszheim > And the soname would read something like: >> $ readelf -a /usr/lib/libboost_date_time-mt.so | grep -i soname >> 0x000e (SONAME) Library soname: >> [libboost_date_time-mt.so.4] >> (that example is taken from Fedora 11, with Boost 1.37.0; the