Subject: Re: [boost] Using both boost 64 and 32 bit on Windows with CMake
From: Klaim - JoÃ«l Lamotte (mjklaim_at_[hidden])
Date: 2013-04-17 08:50:07
On Wed, Apr 17, 2013 at 12:50 PM, Mathias Gaunard <
> Most libraries do not encode half as much data as what Boost encodes in
> its versioned naming scheme.
I don't see the relationship with the point I'm making.
> Most libraries certainly do not care about 32 or 64 bits, it's two
> configuratons you set up and compile separately, like building for two
> different architectures.
Well all other libraries I use so far do care. Also, I don't see what you
want to mean here because I agree it's two different configurations, it is
not at all the point here.
The point is to simplify
> For example there is no conventional place to install boost on windows
> There is, C:\Boost.
> That's the default installation directory of the Boost windows installers.
I know, it's one of the locations, with BOOST_DIR, where CMake's FindBoost
module will look in.
This is not the problem.
> Of course you cannot put both 32 or 64 bit in there without making
This is the problem exactly that I'm pointing. I can obviously set the
library dir using BOOST_LIBRARYDIR
but I then have to do it each time I need to work on CMake files of the
projects and need to delete cache and
configure from scratch.
> TBB puts its libs in intel64 or ia32 sub directories which isn't all
>> that common of a naming scheme in my experience but is certainly usable.
> It's a naming scheme that is used by all Intel libraries (and it's not
> even that consistent, some versions of TBB also have intel64/gc4.4 for
> It's not used by all libraries everywhere.
> I know of many pieces of software which use an approach like that but with
> different directory names.
> Some will use a full triplet like x86_64-linux-gnu some will use weird
> names like glnxa64 etc.
I don't understand what is your point here?
CMake's FindTBB knows that convention which helps it find the right
binaries depending on the configuration/architecture choosen
which is what I point is lacking with Boost, because of the lack of
I'm not saying boost should use one convention in particular, just that it
should provide a convention so that I or someone can patch the FindBoost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk