Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection

Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-04-24 04:58:32

On Thu, Apr 23, 2015 at 10:28 PM, Vladimir Prus <vladimir_at_[hidden]>
wrote:

> On 04/23/2015 10:02 PM, mloskot wrote:
>
>> Klaim - Joël Lamotte wrote
>>
>>> On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev &lt;
>>>
>>
>>  andrey.semashev@
>>>
>>
>>  &gt;
>>> wrote:
>>>
>>>  So my vote is for building 64-bit binaries on a 64-bit system by
>>>> default. This is also consistent with other systems.
>>>>
>>>>
>>> Even with that, having no way for tools (like CMake) to identify one
>>> version from the other is problematic when you actually need to support
>>> both.
>>> Both building the OS native binaries and having a convention to identify
>>> both 32 and 64bit versions would help.
>>>
>>
>> I second that too.
>> As a user of CMake+Boost tandem, I find the issue a PITA indeed.
>>
>
> Is this problem unique to Boost? Does any other library encode 32 vs 64
> bit variant in library name?
>
>
In my current projects dependencies yes, but it's the same problem for any
library that
use the same path and filename for the output of compilation whatever the
target architecture.

As pointed by Andrey, most other libraries (including all the dependencies
I use in all my projects except boost)
will just use a different filename or directory path for the compilation
output depending on the architecture (and build mode).
They also distribute binaries with the same path organisation as the
initial output (without moving files around)
so that tools that easily identify right the binaries using their location.

> I might not know lot about Windows development, but often library names
> does not encode anything really, and
> there are separate "Program Options" for 32-bit and 64-bit. And on Linux,
> 32-bit and 64-bit is also
> in different places, with library names being the same.
>
>
First, Program Files is supposed to be for installed programs or libraries.
Most development work do not end there because these directories have
special meaning and access rights protections (starting with Vista).
If like me you prefer to compile boost yourself to be able to quickfix when
necessary (or other dev-related reasons)
you do not put anything dev-related into Program Files.
(note that most devs on windows will have a directory for development which
is never in Program Files, most of the time in either user
directory or close to the root directory of the disk to avoid too long path
issues that can happen on windows when generating files in
deep directory hierarchies)

Most other libraries providing binaries as said before will provide
different paths for different modes/arch
in the same binary package so that the user have one location with both
binaries and sources/headers,
like a freshly compiled version.

Having only one location to look for both binaries also helps tools.
At the moment, CMake FindBoost.cmake module will use the (unique) BOOST_DIR
environment variable
to guess the boost directory location, or ask the user if there is none
provided.
Once found, CMake cannot guess if it's 64 or 32 bits because
nothing from boost conventions says so, so the user either have to specify
which binaries to use
separately using Boost_LIBRARYDIR or get link-time errors (very too late)
when the CMake module
finds a 64bit boost but the user is compiling a 32bit project (CMake,
again, have no way to know that
boost binaries were 64bit).

Also, on linux, if you build your own boost (because fixes or something
else), don't you NOT install it
into the linux library dirs? I thought you would do it only for distributed
versions of libraries.

> So why is Boost special?
>
>
Boost don't have a way to identify if the binaries are 64 or 32bits.
That's really the core root of the problem
and would easily be fixed with any convention.
Location don't help if the build system
of the library don't enforce that location convention, so that tool knows
where is what.
As soon as it is provided, it will be easy to fix the CMake module
or any tool that try to identify from a boost install.

I also gave other details on the issue in the trac ticket
https://svn.boost.org/trac/boost/ticket/10141

> --
> Vladimir Prus
> CodeSourcery / Mentor Embedded
> http://vladimirprus.com
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>