On 7/5/17 15:43, Peter Dimov via Boost wrote:

...

Furthermore, my answer to the last question depends on whether this is an optional feature or a compulsory change. In case of the latter, I'm against the change.

Special-casing Boost.Python to not support this feature would be a hassle and a bit hostile to its users, relegating them to a second class, but it's doable.

Having a library that works differently for naming than all the rest seems like a non-starter to me. If the community decides the change is good then it should be for all libraries. michael -- Michael Caisse Ciere Consulting ciere.com

On 05.07.2017 17:43, Peter Dimov via Boost wrote:

Stefan Seefeld wrote:

...

...

I have prepared the pull requests necessary to encode the address-model > (32 or 64) in the library names, which allows placing

On 05.07.2017 17:16, Peter Dimov via Boost wrote: the 32/64 > libraries into the same stage/install directory, and building with > address-model=32,64 in one go.

...

...

What problem is this supposed to solve ?

The same problem solved by encoding all other properties into the library names, such as the variant (debug/release), the runtime-link (static/shared), the Boost version, and so on.

...

How frequently do users need both address-models on the same deployment platform (and in the same path) ?

Those users that develop or maintain software under both address models do. Others don't. If you fall into the latter camp, you wouldn't understand the need for this change and would consider it unnecessary.

That's too simplistic. I write portable software which I want to be able to deploy on many different platforms. I also understand the need for multiple build variants being hosted side-by-side. But while there has been a time when it was common to run 32-bit and 64-bit applications on the same machine, I believe this use-case is in sharp decline, as 64-bit platforms are now the norm (and wherever 32-bit apps are run, it's the only choice).

...

Specifically, is this an optional change, or a compulsory one ?

It's not clear how this could be an "optional" change. When you issue the command "b2 install", the libraries have to be named somehow.

Of course. I would expect the `b2 install` to work just as before, without any change. There could be a new command-line option (or even feature) that indicates whether the address-model should be included in the name (similar to the --layout parameter). Though I admit the implied complexities, especially with auto-linking enabled, are substantial. This is exactly why I'm questioning the usefulness of this whole idea. Have any alternatives been considered ? What about changing the installation path for library files ? (this is how Linux deals with "multi-libs".)

...

Would the change mean that all boost libraries would henceforth contain the address-model in their names, and thus that all boost users would have to adjust their own build instructions ?

Yes, if they use --layout=versioned, which is the default on Windows. No, if they don't, which is the default on Linux.

...

Furthermore, my answer to the last question depends on whether this is an optional feature or a compulsory change. In case of the latter, I'm against the change.

Special-casing Boost.Python to not support this feature would be a hassle and a bit hostile to its users, relegating them to a second class, but it's doable.

I'm not talking about Boost.Python. You asked on the list what people (developers and users, I suppose) thought, and so I replied. I definitely do not want Boost.Python to be treated any different. My opinion concerns all of Boost. In a nutshell: this is clearly a change where we need to closely look at the cost/benefit ratio. And since (without further data) this seems to benefit only very few people, I think it's too high a price. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 6 July 2017 at 00:04, Stefan Seefeld via Boost wrote:

On 05.07.2017 17:43, Peter Dimov via Boost wrote:

...

Stefan Seefeld wrote:

...

...

I have prepared the pull requests necessary to encode the address-model > (32 or 64) in the library names, which allows placing

On 05.07.2017 17:16, Peter Dimov via Boost wrote: the 32/64 > libraries into the same stage/install directory, and building with > address-model=32,64 in one go.

...

...

What problem is this supposed to solve ?

The same problem solved by encoding all other properties into the library names, such as the variant (debug/release), the runtime-link (static/shared), the Boost version, and so on.

...

How frequently do users need both address-models on the same deployment platform (and in the same path) ?

Those users that develop or maintain software under both address models do. Others don't. If you fall into the latter camp, you wouldn't understand the need for this change and would consider it unnecessary.

That's too simplistic. I write portable software which I want to be able to deploy on many different platforms. I also understand the need for multiple build variants being hosted side-by-side. But while there has been a time when it was common to run 32-bit and 64-bit applications on the same machine, I believe this use-case is in sharp decline, as 64-bit platforms are now the norm (and wherever 32-bit apps are run, it's the only choice).

This is not really what is happening. There is indeed a slow migration toward 64bit for a big number of applications but it's not all applications that benefiting from it and there are reasons to keep 32bit as an alternative, either because you want benefits from 32bit arch (memory consumption, sometime speed, sometime binary size) or you need to allow your client to chose themself which version si best for their use case. In any way, having a default authoritative way to identify the Boost binaries helps a lot when you are in these cases, as the build tools can finally select them for linking without having to make assumptions and without forcing you to always specify a specific directory where the right library binaries are.

...

...

Specifically, is this an optional change, or a compulsory one ?

It's not clear how this could be an "optional" change. When you issue the command "b2 install", the libraries have to be named somehow.

Of course. I would expect the `b2 install` to work just as before, without any change. There could be a new command-line option (or even feature) that indicates whether the address-model should be included in the name (similar to the --layout parameter). Though I admit the implied complexities, especially with auto-linking enabled, are substantial. This is exactly why I'm questioning the usefulness of this whole idea.

It would prevent tools to have a default way to find the correct libaries as they cannot assume that your build or distribution chose to use that supposed additional flag to make sur the names were augmented.

Have any alternatives been considered ? What about changing the installation path for library files ? (this is how Linux deals with "multi-libs".)

I think that as long as there is a default authoritative organistion to identify the libraries, it's enough to help with the problems from missing them. However, I remember some discussions in the past about a potential solution where, if my memory is correct, considering the alternatives, the majority prefered to have the info in the file names. My memory is a bit blurry on that particular discussion, and it was at least a year ago, so I may be wrong.

...

...

Would the change mean that all boost libraries would henceforth contain the address-model in their names, and thus that all boost users would have to adjust their own build instructions ?

Yes, if they use --layout=versioned, which is the default on Windows. No, if they don't, which is the default on Linux.

...

Furthermore, my answer to the last question depends on whether this is an optional feature or a compulsory change. In case of the latter, I'm against the change.

Special-casing Boost.Python to not support this feature would be a hassle and a bit hostile to its users, relegating them to a second class, but it's doable.

I'm not talking about Boost.Python. You asked on the list what people (developers and users, I suppose) thought, and so I replied. I definitely do not want Boost.Python to be treated any different. My opinion concerns all of Boost.

In a nutshell: this is clearly a change where we need to closely look at the cost/benefit ratio. And since (without further data) this seems to benefit only very few people, I think it's too high a price.

Stefan

Joël Lamotte

On 05.07.2017 23:30, Stefan Seefeld via Boost wrote:

What problem is this supposed to solve ? How frequently do users need both address-models on the same deployment platform (and in the same path) ?

I built executables for distribution on Windows (ie in an installer), where I provided both 32bit and 64bit versions of the program. Being able to have both variants of the compiled libraries in the same directory would have simplified the usage of Boost. Given that 32bit versions of Windows are still rather common, I imagine this is still a quite relevant scenario for Windows applications built with Boost. Just my 2 cents :) Cheers - Asbjørn

On Wed, Jul 5, 2017 at 3:07 PM, Stefan Seefeld via Boost wrote:

While 32-bit systems may still exist, I find it extremely rare that someone with a 64-bit system wants to run 32-bit applications.

It happens multiple times per day for me. Every time I launch a build on Travis or do a full build of all configurations locally.

On 05.07.2017 18:22, Peter Dimov via Boost wrote:

Stefan Seefeld wrote:

...

Why not build separate 32-bit and 64-bit installers, as lots of other applications do ?

Why does this matter?

Because they could use distinct installation prefixes to avoid conflicts. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 05.07.2017 18:32, Vinnie Falco via Boost wrote:

On Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost wrote:

...

Because they could use distinct installation prefixes to avoid conflicts. As a developer working primarily on Windows who regularly builds both 32-bit and 64-bit address models, its a hassle to have different installation prefixes. There's no "standard" place for link libraries on Windows so I have to define BOOST_ROOT in my environment. There's no provision for having two different BOOST_LIBRARYDIR one for 32-bit and one for 64-bit. I end up having to manually edit my project file every time.

Have you encountered this problem on Windows when trying to build the same application using both 32-bit and 64-bit boost variations? I'm very rarely building on Windows, and almost never using Visual Studio. My main development platform is Linux, and I regularly cross-compile or build (remotely, in a VM, etc.) on a range of other

That's unfortunate indeed. platforms (OSX, ARM, etc.). This may explain the cultural difference... :-) Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Jul 5, 2017, at 5:32 PM, Vinnie Falco via Boost wrote:

On Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost wrote:

...

Because they could use distinct installation prefixes to avoid conflicts.

As a developer working primarily on Windows who regularly builds both 32-bit and 64-bit address models, its a hassle to have different installation prefixes. There's no "standard" place for link libraries on Windows so I have to define BOOST_ROOT in my environment.

You should just need to define CMAKE_PREFIX_PATH as that is the variable you use in cmake to tell it where dependencies are(even on windows). Using BOOST_ROOT is more for refining how boost is found when multiple version exists in the CMAKE_PREFIX_PATH. So if you install all your dependencies(ie boost, openssl, zlib, etc) in some directory say C:\deps32 and C:\deps64 then all you need to do is set the CMAKE_PREFIX_PATH for each version: alias cmake32=‘cmake -G \'Visual Studio 14 2015\' -DCMAKE_PREFIX_PATH=C:\deps32 -DCMAKE_INSTALL_PREFIX=C:\deps32’ alias cmake64=‘cmake -G \'Visual Studio 14 2015 Win64\' -DCMAKE_PREFIX_PATH=C:\deps64 -DCMAKE_INSTALL_PREFIX=C:\deps64’ Then cmake32/cmake64 sets up cmake with the different address models, and there is no need to worry about setting custom variables such as BOOST_ROOT. You just create separate build trees for each variant instead.

On Jul 7, 2017, at 3:26 AM, Olaf van der Spek wrote:

On Fri, Jul 7, 2017 at 3:46 AM, P F via Boost wrote:

...

You should just need to define CMAKE_PREFIX_PATH as that is the variable you use in cmake to tell it where dependencies are(even on windows). Using BOOST_ROOT is more for refining how boost is found when multiple version exists in the CMAKE_PREFIX_PATH. So if you install all your dependencies(ie boost, openssl, zlib, etc) in some directory say C:\deps32 and C:\deps64 then all you need to do is set the CMAKE_PREFIX_PATH for each version:

alias cmake32=‘cmake -G \'Visual Studio 14 2015\' -DCMAKE_PREFIX_PATH=C:\deps32 -DCMAKE_INSTALL_PREFIX=C:\deps32’ alias cmake64=‘cmake -G \'Visual Studio 14 2015 Win64\' -DCMAKE_PREFIX_PATH=C:\deps64 -DCMAKE_INSTALL_PREFIX=C:\deps64’

Then cmake32/cmake64 sets up cmake with the different address models, and there is no need to worry about setting custom variables such as BOOST_ROOT. You just create separate build trees for each variant instead.

I'd like to build all variants in one go.. having to cd to each build tree manually is cumbersome.

There is no need to cd into each build directory. The `--build` flag takes the build directory, and like I showed in another email, you can build everything all in one go with: ls -1 | xargs -n1 -I {} cmake --build {} --config Release Or you could do: alias b='ls -1 | xargs -n1 -I {} cmake --build {} --config Release’ So all you have to type is `b` and it builds everything in one go.

Stefan Seefeld wrote:

On 05.07.2017 18:22, Peter Dimov via Boost wrote:

...

Stefan Seefeld wrote:

...

Why not build separate 32-bit and 64-bit installers, as lots of other applications do ?

Why does this matter?

Because they could use distinct installation prefixes to avoid conflicts.

By the same logic, you could use distinct installation prefixes for debug/release. One of these does not even need an installer. Also, you could use distinct installation prefixes for different toolsets, or for different Boost releases. As I said, if you don't use --layout=versioned, this change would seem inexplicable. If you do, it's a straightforward extension, we just encode one more property in the name, one that should have been added in 2005. As I also said, if you don't use --layout=versioned, you're unaffected. (I've conservatively left --layout=tagged unchanged, because I'm not familiar with its real-world uses.)

Stefan Seefeld wrote:

Fair enough. But it's a change, and as such, it comes at a price. (And we haven't even talked about Andrey's comment:

...

Does it only include the address model without the architecture? If yes, it doesn't really solve the problem since you'll still have the same issue when you compile 32-bit x86 and ARM binaries, for example.

In Boost.Build, the architecture (arm mips1 power sparc x86 combined) is a separate property from the address model (32 64). In principle, we could also encode the architecture. My impression though, based on observing earlier discussions, is that tying the address model issue to the architecture issue is a very effective way to stall progress and ultimately do nothing.

On 07/06/17 02:18, Peter Dimov via Boost wrote:

My impression though, based on observing earlier discussions, is that tying the address model issue to the architecture issue is a very effective way to stall progress and ultimately do nothing.

Why? I think, breaking the world twice (first by adding address-model to the names, then by adding architecture) is worse than breaking it once (by adding both). There's little difference from the implementation point (I think) and I don't remember there being opposition to adding architecture as well.

Andrey Semashev wrote:

I think, breaking the world twice (first by adding address-model to the names, then by adding architecture) is worse than breaking it once (by adding both).

Fair point, although I think that "breaking the world" is a slight exaggeration.

There's little difference from the implementation point (I think)...

Not quite true because <address-model> is already supported by the relevant Boost.Build rule, which is why the patch is so trivial, while the architecture isn't. But I'll see what I can do.

Andrey Semashev wrote:

On 07/07/17 01:56, Peter Dimov via Boost wrote:

...

Andrey Semashev wrote:

...

There's little difference from the implementation point (I think)...

Not quite true because <address-model> is already supported by the relevant Boost.Build rule, which is why the patch is so trivial, while the architecture isn't. But I'll see what I can do.

Thank you, Peter.

You're welcome. https://github.com/boostorg/boost/pull/149

On 7 July 2017 at 20:43, Paul A. Bristow via Boost wrote:

It would be less disruptive to make this break once (especially if, as Niall warns, it drives filename length beyond the Microsoft limit).

The Maximum Path Length Limitation is on the way out, though. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).a... Will boost filesystem v4 incorporate these changes? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On 06.07.2017 00:07, Stefan Seefeld via Boost wrote:

On 05.07.2017 18:00, Asbjørn via Boost wrote:

...

On 05.07.2017 23:30, Stefan Seefeld via Boost wrote:

...

What problem is this supposed to solve ? How frequently do users need both address-models on the same deployment platform (and in the same path) ?

I built executables for distribution on Windows (ie in an installer), where I provided both 32bit and 64bit versions of the program. Why not build separate 32-bit and 64-bit installers, as lots of other applications do ?

I just mentioned the installer to highlight that I built executables for other platform variants than the one I do the building on. Building for others is a fairly common use-case in the open-source world on Windows, in which case you frequently need both 32bit and 64bit versions. Cheers - Asbjørn

Am 06.07.2017 um 06:16 schrieb degski via Boost:

On 6 July 2017 at 01:00, Asbjørn via Boost wrote:

...

Being able to have both variants of the compiled libraries in the same directory would have simplified the usage of Boost.

Suitably configured global .props file(s) (they are different for 32 and 64 bit projects) can just as easily handle seperate directories for 32 and 64 bit libs... I like to keep them seperate so as to not having to think about whether a lib is 32- or 64-bits when I see a lib.

That's pretty much how we do it here with *every* 3rd-party library, not just boost. There is absolutely no need to switch environment variables or edit project files: select the desired configuration from Visual Studio and start building. In some cases we build both 32 and 64 bit side-by-side and create a single combined installer from that - all in one go. That said, changing the layout in the proposed way doesn't buy us anything in our team except for the possible need to modify the build system to support both the old and a new layout. In this sense, it complicates things rather than simplifying them. Ciao Dani

On 6 July 2017 at 08:17, Vinnie Falco via Boost wrote:

That works, sort of, but is not great if you are working on different Boost libraries and you want to switch to a different BOOST_ROOT. And its painful if you are using CMake because then you aren't respecting the results of FindBoost. It can also break in subtle ways, you change the props to an older Boost to diagnose a regression, then you open a new solution and forget to switch and you waste time.

You're having the perspective of a boost-dev. Almost all users are non-devs. You could copy the correct props-file in place with a pre-build command, I guess. CMake is not the generally supported boost build tool, yet or maybe never.

I've limped along with the system of modifying the User Property Sheets (.props) for a few years, but putting 32/64 bit libs in the same dir with different names is a far better solution.

And you suggest I then change the names of all my libs? Personally I'm indifferent to the proposed change, I'll still put them in seperate folders. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On Jul 5, 2017, at 5:00 PM, Asbjørn via Boost wrote:

On 05.07.2017 23:30, Stefan Seefeld via Boost wrote:

...

What problem is this supposed to solve ? How frequently do users need both address-models on the same deployment platform (and in the same path) ?

I built executables for distribution on Windows (ie in an installer), where I provided both 32bit and 64bit versions of the program.

CPack can package binaries across different build trees, so it can easily create an installer with both 32/64 bit binaries without both binaries being in the same build. For other packaging tools, its possible as well, just more low-level as you need to manually do the install+package(although still completely automatable).

On 5 July 2017 at 23:44, Niall Douglas via Boost wrote:

...

This being a Serious Change, the prudent thing to do is to wait out 1.65, then proceed.

On the other hand, experience shows that this kind of change is only tested when a release goes out anyway; delaying it for four more months would not help much.

Therefore, I'm calling for opinions; would people want this to go into 1.65? Into 1.66? Not at all?

I can see it may break end user's scripting, but waiting won't help that.

The only showstopper potential is if this change causes the 260 char path limit on Windows to be exceeded. You may not think this a problem, but think of Jenkins etc. Even a few extra chars in a filename can produce weird hard to diagnose failures.

Niall

In my experience, this issue cannot be fixed by tweaking such feature. Also if you want short names for a specific project, my understanding is that it's still possible to chose to do so. Joël Lamotte

On 6 July 2017 at 00:00, Andrey Semashev via Boost wrote:

On 07/06/17 00:16, Peter Dimov via Boost wrote:

...

I have prepared the pull requests necessary to encode the address-model (32 or 64) in the library names, which allows placing the 32/64 libraries into the same stage/install directory, and building with address-model=32,64 in one go.

These are

https://github.com/boostorg/boost/pull/147

and

https://github.com/boostorg/config/pull/159

This being a Serious Change, the prudent thing to do is to wait out 1.65, then proceed.

On the other hand, experience shows that this kind of change is only tested when a release goes out anyway; delaying it for four more months would not help much.

Therefore, I'm calling for opinions; would people want this to go into 1.65? Into 1.66? Not at all?

Does it only include the address model without the architecture? If yes, it doesn't really solve the problem since you'll still have the same issue when you compile 32-bit x86 and ARM binaries, for example. If we want to put binaries to the same directory, I think the name should include the architecture.

I agree. Basically any information that allows tools to differentiate the different versions so that they an chose the right version for one target/project's configuration will help.

In any case, I suspect there'll be a fair amount of discussion, and there should be a fair amount of testing before it is merged to master. I think 1.65 is already closed for beta, so it's probably better to postpone it to 1.66.

Joël Lamotte

On 07/06/17 04:10, Gavin Lambert via Boost wrote:

On 6/07/2017 10:00, Andrey Semashev wrote:

...

If we want to put binaries to the same directory, I think the name should include the architecture.

At build time it's trivial enough to have your x86/64 libraries in one folder and your arm libraries in another; it might be convenient to have them in one place but I don't see this as compelling (but then I don't build arm binaries as a matter of course, so take that with a grain of salt).

The described use case is to be able to build everything in one go, so that all binaries end up in the common stage directory. If we are building in multiple steps then one can use separate stage directories for address-model as well.

On 07/07/17 04:57, P F wrote:

...

On Jul 6, 2017, at 2:52 AM, Andrey Semashev via Boost wrote:

On 07/06/17 04:10, Gavin Lambert via Boost wrote:

...

On 6/07/2017 10:00, Andrey Semashev wrote:

...

If we want to put binaries to the same directory, I think the name should include the architecture. At build time it's trivial enough to have your x86/64 libraries in one folder and your arm libraries in another; it might be convenient to have them in one place but I don't see this as compelling (but then I don't build arm binaries as a matter of course, so take that with a grain of salt).

The described use case is to be able to build everything in one go, so that all binaries end up in the common stage directory.

If you set the same install prefix for each build tree then you can build and install everything in one go:

ls -1 | xargs -n1 -I {} cmake --build {} --config Release --target install

Or you can create a CPackConfig.cmake file, which build the installer for you from each variant all in one go as well:

include("64/CPackConfig.cmake") set(CPACK_INSTALL_CMAKE_PROJECTS "32;Foo;ALL;/" "64;Foo;ALL;/" )

I was talking about building Boost using Boost.Build.