What variants should be build on Windows by default?

Hi, What library variants should be build on Windows by default? Currently it builds: --build-type=<type> Build the specified pre-defined set of variations of the libraries. Note, that which variants get built depends on what each library supports. -- minimal -- (default) Builds a minimal set of variants. On Windows, these are static multithreaded libraries in debug and release modes, using shared runtime. On Linux, these are static and shared multithreaded libraries in release mode. Personally I use a static-release runtime often (for simple deployments). What variants do others use and what should be build by default? Greetings, -- Olaf

On Tue, May 5, 2015 at 7:20 PM, Olaf van der Spek
Hi,
What library variants should be build on Windows by default?
Currently it builds: --build-type=<type> Build the specified pre-defined set of variations of the libraries. Note, that which variants get built depends on what each library supports.
-- minimal -- (default) Builds a minimal set of variants. On Windows, these are static multithreaded libraries in debug and release modes, using shared runtime. On Linux, these are static and shared multithreaded libraries in release mode.
Personally I use a static-release runtime often (for simple deployments). What variants do others use and what should be build by default?
(my experience with boost might not be representative) I use the static versions of both debug and release for almost all my projects (which works on windows), though for some projects I need the shared version. There is one long-term-dev cross-platform project which currently uses static boost libraries but I realized recently that I will have to switch to shared versions very soon. By default I tend to always start with the static version [1], but it tend to evolve/change the more the projects grows and I split it in separate binaries. I build everything (static&shared, debug&release, 32&64bits) each time there is a new boost release I want to use in one of the projects, then I target the version I want to use for each project separately. [2] (note: I always use shared runtime) I don't have a preference for the default build type on windows, as I explicitly build all types. Maybe having the same rule for all platforms (shared?) would avoid surprises for users. Maybe defaulting to static on windows is so common that it should be the default. By the way, did you consider not having a default? (requiring to explicitly state which build type to use?) [1] To avoid having to setup scripts moving dlls around, boost is never "installed" on my dev computer as I use several versions depending on the project. [2] I build myself to be able to quickly patch boost when needed.
Greetings,
-- Olaf
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 05.05.2015 19:20, Olaf van der Spek wrote:
What library variants should be build on Windows by default?
FWIW, as a user: Unless something else requires it I prefer static with shared runtime. This is what we use for the open source project I'm part of as well. Almost all non-trivial Boost code I've used has been too convoluted to sensibly trace through, so I only build the debug versions as a last ditch attempt to finding a bug. - Asbjørn

On 6/05/2015 05:20, Olaf van der Spek wrote:
What library variants should be build on Windows by default?
Currently it builds: --build-type=<type> Build the specified pre-defined set of variations of the libraries. Note, that which variants get built depends on what each library supports.
-- minimal -- (default) Builds a minimal set of variants. On Windows, these are static multithreaded libraries in debug and release modes, using shared runtime. On Linux, these are static and shared multithreaded libraries in release mode.
Personally I use a static-release runtime often (for simple deployments). What variants do others use and what should be build by default?
With the Boost internal defaults, building static multithreaded in both debug and release is probably the right thing to do as a minimal default. Some applications (notably those that use non-header-only Boost classes in the API between multiple DLLs or between DLL and EXE) may need to use shared libraries instead, but these will also need to define BOOST_ALL_DYN_LINK as well, so it's not a minimal build, but should probably be included in the next-higher tier.
participants (4)
-
Asbjørn
-
Gavin Lambert
-
Klaim - Joël Lamotte
-
Olaf van der Spek