Encoding address-model in library names
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?
On 05.07.2017 17: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.
Vinnie Falco originally wrote:
I'd like to avoid a lengthy debate, and if no one wants to do it just provide me with working code for accomplishing it and I'll submit a pull request.
Given how intrusive a change that is, I'd like to understand a bit better what change he had in mind precisely, and what the effect of the below PRs are. Specifically, is this an optional change, or a compulsory one ? 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 ? 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) ?
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?
I really don't think a change of that nature should go in without discussion. 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. Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
On 05.07.2017 17: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.
...
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.
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.
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.
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 18:02, Michael Caisse via Boost wrote:
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.
Agreed, Stefan
michael
-- ...ich hab' noch einen Koffer in Berlin...
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...
Stefan Seefeld wrote:
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).
100% of Windows 64 users run both 32 and 64 applications on the same machine. But this doesn't matter. Having 32 and 64 bit static libraries in the same directory is not in any way connected with whether one runs 32 bit and 64 bit applications on the same machine, even if we posit that this is rare, which it's not. Similarly, users don't run debug and release versions of our software at the same time, yet we encode debug/release in the library name and allow both variants in the same directory. It's as simple as this, in Visual Studio you have one dropdown for Debug/Release, another for 32/64, and you reasonably expect both to be equally well supported.
On 6 July 2017 at 00:04, Stefan Seefeld via Boost <boost@lists.boost.org> 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 5 July 2017 at 23:43, Peter Dimov via Boost <boost@lists.boost.org> 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 the 32/64 >
On 05.07.2017 17:16, Peter Dimov via Boost wrote: 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.
Yes, it made discussions around this change request very difficult as not everyone is in situations where not having this kind of naming is problematic.
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.
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.
Seems like a good default to me.
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.
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 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 ?
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.
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. So dealing with the (slight) inconvenience to have separate paths in these (rare) cases seems more appropriate than having everyone pay the price for the added complexity. Stefan
Just my 2 cents :)
Cheers - Asbjørn
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ...ich hab' noch einen Koffer in Berlin...
On Wed, Jul 5, 2017 at 3:07 PM, Stefan Seefeld via Boost <boost@lists.boost.org> 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 Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost <boost@lists.boost.org> 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?
On 05.07.2017 18:32, Vinnie Falco via Boost wrote:
On Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost <boost@lists.boost.org> 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 6 July 2017 at 00:32, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost <boost@lists.boost.org> 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 reported this problem several times through the years here because it prevent (meta-)build systems like CMake don't have a reliable way to be sure which are the right binaries, and I have to do the same as you each time I cmake, with a sometime different BOOST_LIBARYDIR for differrent applications or the same. I couldn't make a patch because I fail to get how b2 work (although I didn't get in great depths in it) and think it need at least some kind of agreement on some authority around here. Joël Lamotte
On Jul 5, 2017, at 5:32 PM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost <boost@lists.boost.org> 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 Fri, Jul 7, 2017 at 3:46 AM, P F via Boost <boost@lists.boost.org> 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. -- Olaf
On Jul 7, 2017, at 3:26 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Jul 7, 2017 at 3:46 AM, P F via Boost <boost@lists.boost.org> 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.
On Fri, Jul 7, 2017 at 7:49 PM, P F <pfultz2@yahoo.com> wrote:
On Jul 7, 2017, at 3:26 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Fri, Jul 7, 2017 at 3:46 AM, P F via Boost <boost@lists.boost.org> 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
On Windows? This assumes the build dirs have been created and populated already doesn't it? It still seems quite cumbersome.
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.
-- Olaf
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.)
On 05.07.2017 18:52, Peter Dimov via Boost wrote:
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.
Indeed.
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.
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. We should at least follow the naming conventions used by other
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: libraries, using suffixes such as 'x86' and 'x86_64' or somesuch. Just adding a '-32' and '-64' suffix isn't good enough. Or we'll have to change things again in the next release.
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.)
Right. Stefan -- ...ich hab' noch einen Koffer in Berlin...
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 05.07.2017 19:18, Peter Dimov via Boost wrote:
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).
I know.
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.
How so ? Do you expect to get more opposition if you propose to encode both ? I thought the main argument against the change was the fact that it's an intrusive change. Once we agree to a change, the change itself isn't quite as important. In contrast, the fact that this solves an even larger issue would make the patch more acceptable. (Without wanting to open the door to discussing the separation of "architecture" and "address model" in Boost.Build, I do believe that the two should be coupled, at least in the file naming context: In the real world (i.e., outside Boost), these two are always combined into distinct and unambiguous names.) Stefan -- ...ich hab' noch einen Koffer in Berlin...
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.
On Thu, Jul 6, 2017 at 9:58 AM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
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.
This doesn't break the world, does it? Non-Windows isn't affected. Windows auto-linking isn't affected. -- Olaf
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.
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.
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
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 06 July 2017 23:57 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] Encoding address-model in library names
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.
The most important missing details is the address-model. It would seem logical to display the architecture too, but only if this isn't too difficult. It would be less disruptive to make this break once (especially if, as Niall warns, it drives filename length beyond the Microsoft limit). People who are using two folders for /x64 and /win32 (as I am, can continue, or change to a single folder if and when they prefer)? I'd say go for it asap. I'm not sure it will break much. Let's get over it. And thanks for sorting this out. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 7 July 2017 at 20:43, Paul A. Bristow via Boost <boost@lists.boost.org> 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 6 July 2017 at 01:07, Stefan Seefeld via Boost <boost@lists.boost.org> 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.
When memory is thight, a 32-bit app might just be the right thing to have on a 64-bit system. 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
On 6 July 2017 at 01:00, Asbjørn via Boost <boost@lists.boost.org> 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'm sure there are better and/or more sophisticated ways of doing that as well. 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. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
Am 06.07.2017 um 06:16 schrieb degski via Boost:
On 6 July 2017 at 01:00, Asbjørn via Boost <boost@lists.boost.org> 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 Wed, Jul 5, 2017 at 9:16 PM, degski via Boost <boost@lists.boost.org> wrote:
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.
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. 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.
On 6 July 2017 at 08:17, Vinnie Falco via Boost <boost@lists.boost.org> 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
Sent from mobile. On Jul 6, 2017 7:53 AM, "degski via Boost" <boost@lists.boost.org> wrote: On 6 July 2017 at 08:17, Vinnie Falco via Boost <boost@lists.boost.org> 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 have the same issues, I'm not a boost library developer.
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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On Jul 5, 2017, at 5:00 PM, Asbjørn via Boost <boost@lists.boost.org> 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).
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 -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 5 July 2017 at 23:44, Niall Douglas via Boost <boost@lists.boost.org> 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 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. 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.
On 6 July 2017 at 00:00, Andrey Semashev via Boost <boost@lists.boost.org> 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 6/07/2017 10:00, Andrey Semashev wrote:
On 07/06/17 00:16, Peter Dimov 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. [...]
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 guess the question there is how often people build multi-architecture. On Windows, I see it as relatively common to build both 32-bit and 64-bit applications and libraries. More importantly, there is an installation scenario where an application suite might contain a mixture of 32-bit and 64-bit applications, where it would be convenient to have all the dependent libraries (including Boost) in the same directory, since Windows has a convention of looking in the same directory as the original application for its library dependencies, and you have to jump through a lot of hoops to make it do differently. On the other hand, at runtime you'd never have x86 and ARM libraries in the same folder. 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). So on Windows, there would be a large benefit to discriminating between 32-bit and 64-bit, and little-to-no benefit to discriminating between architectures. On Linux, it's a moot point, since Linux: (a) doesn't use the versioned file naming layout, so this change doesn't affect them in the first place (b) does have a convention of storing (and looking for) library binaries in architecture+model specific folders rather than in the same folder As for the change itself, I welcome it -- it's not hard to work around the current behaviour (https://stackoverflow.com/a/42408982/43534) but it would be nice not to have to. For most Windows users it shouldn't adversely affect builds (thanks to auto linking) but install packages and the like would probably need to be tweaked for filename changes. While this might annoy some people, as long as it's infrequent and valuable enough (as this seems to be) it should be fine.
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 Jul 6, 2017, at 2:52 AM, Andrey Semashev via Boost <boost@lists.boost.org> 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;/" )
On 07/07/17 04:57, P F wrote:
On Jul 6, 2017, at 2:52 AM, Andrey Semashev via Boost <boost@lists.boost.org> 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.
On 5 July 2017 at 23:16, Peter Dimov via Boost <boost@lists.boost.org> 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?
Yes please. I have been deeply annoyed to have to maintained scripts to be able to use or switch between the different versions easily, allowing this naming by default at least on Windows will simplify a lot tools (for example CMake's find module can finally be modified to link the binaries you need by default, which is not the case when you have for example a 64bit Windows but are compiling a 32bit app). Joël Lamotte
On Wed, Jul 5, 2017 at 4:16 PM, Peter Dimov via Boost <boost@lists.boost.org
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.
What happens if the user leaves off the address-model parameter entirely? I seem to recall that in bjam configs the absence of address-model is different from address-model=32, will that cause different file names? Tom
AMDG On 07/10/2017 08:39 PM, Tom Kent via Boost wrote:
On Wed, Jul 5, 2017 at 4:16 PM, Peter Dimov via Boost <boost@lists.boost.org
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.
What happens if the user leaves off the address-model parameter entirely? I seem to recall that in bjam configs the absence of address-model is different from address-model=32, will that cause different file names?
That used to be the case, but address-model is now auto-detected by Jamroot. In Christ, Steven Watanabe
participants (16)
-
Andrey Semashev -
Asbjørn -
Daniela Engert -
degski -
Gavin Lambert -
Klaim - Joël Lamotte -
Michael Caisse -
Niall Douglas -
Olaf van der Spek -
P F -
Paul A. Bristow -
Peter Dimov -
Stefan Seefeld -
Steven Watanabe -
Tom Kent -
Vinnie Falco