[1.35.0] Build/install (attn: release team)
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. But also because it generates a dizzying array of library files and hence people have a hard time understanding what to link to. The old real way to "solve" this is to reduce the number of variants we build by default. So the current favorite is to only build: * multi-threaded, shared runtime, release This seems to be the most used and most immediately useful variant in the majority of platforms. It also happens to be, other than release vs. debug, the only possible variant in some platforms. So if no one has objections to this choice I, with help from Volodya, will change this by the end of the week. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Tue, 23 Oct 2007 11:56:46 -0500, Rene Rivera wrote
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. But also because it generates a dizzying array of library files and hence people have a hard time understanding what to link to.
The old real way to "solve" this is to reduce the number of variants we build by default. So the current favorite is to only build:
* multi-threaded, shared runtime, release
This seems to be the most used and most immediately useful variant in the majority of platforms. It also happens to be, other than release vs. debug, the only possible variant in some platforms.
So if no one has objections to this choice I, with help from Volodya, will change this by the end of the week.
I'm in support of this change. Jeff
On Oct 23, 2007, at 12:56 PM, Rene Rivera wrote:
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. But also because it generates a dizzying array of library files and hence people have a hard time understanding what to link to.
The old real way to "solve" this is to reduce the number of variants we build by default. So the current favorite is to only build:
* multi-threaded, shared runtime, release
Good. Will the names of the resulting libraries be mangled or not? Mangling those names seems like a good idea on Windows, not such a good idea on *nix. - Doug
Douglas Gregor wrote:
On Oct 23, 2007, at 12:56 PM, Rene Rivera wrote:
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. But also because it generates a dizzying array of library files and hence people have a hard time understanding what to link to.
The old real way to "solve" this is to reduce the number of variants we build by default. So the current favorite is to only build:
* multi-threaded, shared runtime, release
Volodya pointed out that that might be misleading of me since I made a usual assumption. What I meant was: multi-threaded, shared, release. Meaning shared libraries, and hence shared runtime.
Good. Will the names of the resulting libraries be mangled or not?
No. That would involve changes to the auto-linking code which would cause a cascade of failures, and not just in our own testing. We
Mangling those names seems like a good idea on Windows, not such a good idea on *nix.
What we can do for Unix is to make the untagged symlinks point to the default variant. That way the simple default usage on Unix does the expected. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Douglas Gregor wrote:
On Oct 23, 2007, at 12:56 PM, Rene Rivera wrote:
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. But also because it generates a dizzying array of library files and hence people have a hard time understanding what to link to.
The old real way to "solve" this is to reduce the number of variants we build by default. So the current favorite is to only build:
* multi-threaded, shared runtime, release
Volodya pointed out that that might be misleading of me since I made a usual assumption. What I meant was: multi-threaded, shared, release. Meaning shared libraries, and hence shared runtime.
This is a pet peeve of mine - I tend to favor static linkage because I always know what I get at runtime, no matter if there are multiple DLLs in the path or not. Also, it is much easier during development and testing as I don't need to make sure that the .exes will find the shared libraries.
Good. Will the names of the resulting libraries be mangled or not?
No. That would involve changes to the auto-linking code which would cause a cascade of failures, and not just in our own testing. We
Mangling ... do you mean tagging? Why should they not be tagged by default? / Johan
Hi.
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build.
Ok, it does take about 10-15 minutes to build everything on our machines here (Windows XP). But I personally like the simple way of building 'everything'. We use the debug libraries mostly for development as it gets us better insight (e.g. watches) when tracking down bugs (e.g. passed incorrect ponters or references) detected somewhere deep inside boost code. Also different projects of ours use rather different variants of boost (e.g. static/shared runtime) and we never had a problem linking to correct libraries (autolink functionality on windows rocks :-)) and on Linux it was never a problem listing the correct libraries for different build options using boost.build :-))) ). Anyway... I would really hate it if someone decided to change the name mangling for different build types or if it became difficult to tell boost build to 'build all variants as it did before by default'. Thanks... Best regards, Jurko Gospodnetić
Jurko Gospodnetic' wrote:
Hi.
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build.
Ok, it does take about 10-15 minutes to build everything on our machines here (Windows XP). But I personally like the simple way of building 'everything'.
Hm... [...]
Anyway... I would really hate it if someone decided to change the name mangling for different build types or if it became difficult to tell boost build to 'build all variants as it did before by default'.
It depends on what you consider difficult. It would mean specifying something like: bjam release debug link=static ... etc. But perhaps we can make this much simpler. How about adding an option that selects how much is built with some easy to remember names? Something like: --build-type=minimal (default single variant) --build-type=complete (as many variants as possible) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
[mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Tuesday, October 23, 2007 1:05 PM To: boost@lists.boost.org Subject: Re: [boost] [1.35.0] Build/install (attn: release team) <snip> But perhaps we can make this much simpler. How about adding an option that selects how much is built with some easy to remember names? Something like:
--build-type=minimal (default single variant)
--build-type=complete (as many variants as possible)
If you do change it, I would vote for this format. I also tend to use most of the different variants so reducing it down to a single option to get it back to the way it used to build would be greatly appreciated. Regards, Matt Scanned by McAfee GroupShield {X3BTB534}
Rene Rivera wrote:
Jurko Gospodnetic' wrote:
Hi.
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. Ok, it does take about 10-15 minutes to build everything on our machines here (Windows XP). But I personally like the simple way of building 'everything'.
Hm...
[...]
Anyway... I would really hate it if someone decided to change the name mangling for different build types or if it became difficult to tell boost build to 'build all variants as it did before by default'.
It depends on what you consider difficult. It would mean specifying something like:
bjam release debug link=static ... etc.
But perhaps we can make this much simpler. How about adding an option that selects how much is built with some easy to remember names? Something like:
--build-type=minimal (default single variant)
--build-type=complete (as many variants as possible)
That seems like a good solution. --Beman
Rene Rivera wrote:
Jurko Gospodnetic' wrote:
Hi.
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build.
Ok, it does take about 10-15 minutes to build everything on our machines here (Windows XP). But I personally like the simple way of building 'everything'.
Hm...
[...]
Anyway... I would really hate it if someone decided to change the name mangling for different build types or if it became difficult to tell boost build to 'build all variants as it did before by default'.
It depends on what you consider difficult. It would mean specifying something like:
bjam release debug link=static ... etc.
But perhaps we can make this much simpler. How about adding an option that selects how much is built with some easy to remember names? Something like:
--build-type=minimal (default single variant)
--build-type=complete (as many variants as possible)
And what would be the behaviour of use specified --build-type=XXX together with some explicit options. Well, I actually know the most easily implementable one, but I'm not sure it will be intuitive. - Volodya
Hi.
Something like:
--build-type=minimal (default single variant)
--build-type=complete (as many variants as possible)
And what would be the behaviour of use specified --build-type=XXX together with some explicit options. Well, I actually know the most easily implementable one, but I'm not sure it will be intuitive.
I vote for the following (in the order of preference): - make build-type have less priority so parts of it can be overridden. - apply them in the order specified Btw... when this is implemented, could someone add a description of how to implement such an option in the boost build documentation? It would be in line with the planned documentation effort and the documentation does lack such 'real world' examples for extending a default boost build. Best regards, Jurko Gospodnetic'
Vladimir Prus wrote:
Rene Rivera wrote:
[snip]
But perhaps we can make this much simpler. How about adding an option that selects how much is built with some easy to remember names? Something like:
--build-type=minimal (default single variant)
--build-type=complete (as many variants as possible)
And what would be the behaviour of use specified --build-type=XXX together with some explicit options. Well, I actually know the most easily implementable one, but I'm not sure it will be intuitive.
1) Ignore "--build-type", possibly emit a warning, and behave as currently? 2) Expand the build type, add/override the explicit options? / Johan
Rene Rivera wrote:
Jurko Gospodnetic' wrote:
Hi.
[snip]
[...]
Anyway... I would really hate it if someone decided to change the name mangling for different build types or if it became difficult to tell boost build to 'build all variants as it did before by default'.
It depends on what you consider difficult. It would mean specifying something like:
bjam release debug link=static ... etc.
But perhaps we can make this much simpler. How about adding an option that selects how much is built with some easy to remember names? Something like:
--build-type=minimal (default single variant)
--build-type=complete (as many variants as possible)
I think this is a breaking change. Shouldn't the previous behaviour remain the current default, at least until 1.36 (introduce the option to try it out, and then change to default if it turns out to be commonly used)? / Johan
Rene Rivera wrote:
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. But also because it generates a dizzying array of library files and hence people have a hard time understanding what to link to.
The old real way to "solve" this is to reduce the number of variants we build by default. So the current favorite is to only build:
* multi-threaded, shared runtime, release
I'm not part of the release team, so sorry for intruding ... Boost.C++ is a foundation for developers to build their own application and/or libraries, right - so: Are there any developers that do _not_ use the debug builds of the libraries? / Johan
Johan Nilsson wrote:
Rene Rivera wrote:
The topic of what gets built "out of the box" came up again, this time on IRC. Some background... In the past we have gone the route of building as much as possible when users do the manual Boost build+install. That approach has gotten us a rather distressing reputation of building being a real pain, mostly because it takes a long time to build. But also because it generates a dizzying array of library files and hence people have a hard time understanding what to link to.
The old real way to "solve" this is to reduce the number of variants we build by default. So the current favorite is to only build:
* multi-threaded, shared runtime, release
I'm not part of the release team, so sorry for intruding ...
Boost.C++ is a foundation for developers to build their own application and/or libraries, right - so: Are there any developers that do _not_ use the debug builds of the libraries?
Do you regularly debug C++ Boost? Most bug reports I see do not even include a backtrace, not to mention pinpointing specific wrong line in code. Note also that nowdays, many folks build Boost because it's dependency of some other application -- in which case it's even less likely the person would like to debug C++ Boost. - Volodya
Vladimir Prus wrote:
Johan Nilsson wrote:
[snip]
Boost.C++ is a foundation for developers to build their own application and/or libraries, right - so: Are there any developers that do _not_ use the debug builds of the libraries?
Do you regularly debug C++ Boost? Most bug reports I see do not even include a backtrace, not to mention pinpointing specific wrong line in code.
I regularly debug _into_ C++ Boost (when I'm forced to debug, that is). I don't debug Boost C++ per se, even if it has happened; e.g. when I ran into some problems with Boost.Thread. I don't wan't do mix debug and release variants (it's most often not even possible), and during development I'm working with debug versions approximately 90+ percent of the time.
Note also that nowdays, many folks build Boost because it's dependency of some other application -- in which case it's even less likely the person would like to debug C++ Boost.
And what are the chances that this "minimal build" is the exact build that the other application depends on? IMHO, if another application depends on the Boost libraries, that application's development team should also provide an instruction on how to get/install its dependencies. / Johan
Johan Nilsson wrote:
Vladimir Prus wrote:
Johan Nilsson wrote:
[snip]
Boost.C++ is a foundation for developers to build their own application and/or libraries, right - so: Are there any developers that do _not_ use the debug builds of the libraries?
Do you regularly debug C++ Boost? Most bug reports I see do not even include a backtrace, not to mention pinpointing specific wrong line in code.
I regularly debug _into_ C++ Boost (when I'm forced to debug, that is). I don't debug Boost C++ per se, even if it has happened; e.g. when I ran into some problems with Boost.Thread.
I don't wan't do mix debug and release variants (it's most often not even possible), and during development I'm working with debug versions approximately 90+ percent of the time.
Note also that nowdays, many folks build Boost because it's dependency of some other application -- in which case it's even less likely the person would like to debug C++ Boost.
And what are the chances that this "minimal build" is the exact build that the other application depends on?
IMHO, if another application depends on the Boost libraries, that application's development team should also provide an instruction on how to get/install its dependencies.
On Linux, when using package management, most dependencies on libraries are on release version. Just to clarify -- I have no idea what's the sane default on windows. - Volodya
Vladimir Prus wrote:
Johan Nilsson wrote:
Vladimir Prus wrote:
[snip]
Note also that nowdays, many folks build Boost because it's dependency of some other application -- in which case it's even less likely the person would like to debug C++ Boost.
And what are the chances that this "minimal build" is the exact build that the other application depends on?
IMHO, if another application depends on the Boost libraries, that application's development team should also provide an instruction on how to get/install its dependencies.
On Linux, when using package management, most dependencies on libraries are on release version. Just to clarify -- I have no idea what's the sane default on windows.
For prebuilt, installable, applications the norm is of course the release version. But if an application depends on a third-party library, such dependencies should be included in binary form within the installer package. This was however not what I was referring to above - I was thinking about the cases where one would download the source code to e.g. some Open Source project which depends on Boost. The purpose could be either for development or as a plain end user. / Johan
Vladimir Prus wrote:
Do you regularly debug C++ Boost?
It doesn't matter. One typical use case is include a Boost header, wait for the linker error calling for a missing libboost_foo-vc80-mt-whatever.lib, then somehow figure out a way to build it. If the autolink code selects a debug library, this is what the user needs, regardless of whether he intends to debug into Boost. On a related note, the obvious way to build libboost_foo-vc80-mt-whatever.lib: bjam libboost_foo-vc80-mt-whatever.lib didn't work last I tried it.
Peter Dimov wrote:
Vladimir Prus wrote:
Do you regularly debug C++ Boost?
It doesn't matter. One typical use case is include a Boost header, wait for the linker error calling for a missing libboost_foo-vc80-mt-whatever.lib, then somehow figure out a way to build it. If the autolink code selects a debug library, this is what the user needs, regardless of whether he intends to debug into Boost.
As I say in another email, I don't know what's sane for Windows. I think I do know what's sane for Linux though, and that's MT, shared, release.
On a related note, the obvious way to build libboost_foo-vc80-mt-whatever.lib:
bjam libboost_foo-vc80-mt-whatever.lib
didn't work last I tried it.
Did you do that in libs/foo/build? Or from top-level? The latter is not supposed to work, although it's probably possible to implement -- can you file an issue? - Volodya
on Wed Oct 24 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
Peter Dimov wrote:
Vladimir Prus wrote:
Do you regularly debug C++ Boost?
It doesn't matter. One typical use case is include a Boost header, wait for the linker error calling for a missing libboost_foo-vc80-mt-whatever.lib, then somehow figure out a way to build it. If the autolink code selects a debug library, this is what the user needs, regardless of whether he intends to debug into Boost.
As I say in another email, I don't know what's sane for Windows. I think I do know what's sane for Linux though, and that's MT, shared, release.
On a related note, the obvious way to build libboost_foo-vc80-mt-whatever.lib:
bjam libboost_foo-vc80-mt-whatever.lib
didn't work last I tried it.
Did you do that in libs/foo/build? Or from top-level? The latter is not supposed to work, although it's probably possible to implement -- can you file an issue?
Done on Peter's behalf: http://svn.boost.org/trac/boost/ticket/1393 -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (11)
-
Beman Dawes -
David Abrahams -
Douglas Gregor -
Jeff Garland -
Johan Nilsson -
Jurko Gospodnetic' -
Jurko Gospodnetić
-
Matt Doyle -
Peter Dimov -
Rene Rivera -
Vladimir Prus