Encoding address-model in library names

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Encoding address-model in library names

Boost - Dev mailing list
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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 05.07.2017 17:43, Peter Dimov via Boost wrote:

> 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.

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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Jul 5, 2017 at 3:07 PM, Stefan Seefeld via Boost
<[hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Stefan Seefeld wrote:

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

Why does this matter?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
On Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost
<[hidden email]> 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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
On 05.07.2017 18:32, Vinnie Falco via Boost wrote:

> On Wed, Jul 5, 2017 at 3:30 PM, Stefan Seefeld via Boost
> <[hidden email]> 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.

That's unfortunate indeed.

> 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
platforms (OSX, ARM, etc.).

This may explain the cultural difference... :-)

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
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.

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.
> 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
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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Encoding address-model in library names

Boost - Dev mailing list
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...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123
Loading...