Default variants on windows
Per: https://svn.boost.org/trac/boost/ticket/2899 we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later. Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built. - Volodya
Vladimir Prus schrieb:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built.
- Volodya
I think it is needed also SCL_SECURE variant! it is really important...
Hansi wrote:
Vladimir Prus schrieb:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built.
- Volodya
I think it is needed also SCL_SECURE variant! it is really important...
I am afraid this is not the answer to my question. If you implicitly suggest that we build 12 variants by default, then I'm afraid this is just not practical. Nobody will have the patience to wait till the build is done. - Volodya
Dear Volodya, as a Windows (and Linux and Mac) developer using boost both from VisualStudio IDE and from autogenerated makefiles of Cmake, I would suggest to either keep it as it is, although MSVC by default opens projects/solutions in debug mode. In other case I would suggest to add also debug mt variants; but building all variants not only takes ages, but also takes a very huge amount of disk space. Kind regards, Carlo Medas On Wed, Apr 8, 2009 at 3:24 PM, Vladimir Prus <vladimir@codesourcery.com>wrote:
Hansi wrote:
Vladimir Prus schrieb:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built.
- Volodya
I think it is needed also SCL_SECURE variant! it is really important...
I am afraid this is not the answer to my question. If you implicitly suggest that we build 12 variants by default, then I'm afraid this is just not practical. Nobody will have the patience to wait till the build is done.
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Vladimir Prus schrieb:
Hansi wrote:
Vladimir Prus schrieb:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built.
- Volodya I think it is needed also SCL_SECURE variant! it is really important...
I am afraid this is not the answer to my question. If you implicitly suggest that we build 12 variants by default, then I'm afraid this is just not practical. Nobody will have the patience to wait till the build is done.
Maybe it is not needed to make all variants, but it is important to make it possible to make all variants and that it is possible to see which one it is. The default may be should be the default of the environment..
Vladimir Prus wrote:
In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution.
Face the truth: On Windows, there are too many of features (no-checked-iterators, SCL_SECURE, autolinking + _DEBUG) "influencing" ABI compatibility that no "default" solution will suit all needs, even if you are accepting excessive build times. The only solution I see is to tell the user that is really easy to build the libraries with different options, and show them that it is really that easy (which it is once you found out how to do it). Regards, Thomas
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Klimpel Sent: 08 April 2009 14:55 To: boost@lists.boost.org Subject: Re: [boost] Default variants on windows
Vladimir Prus wrote:
In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution.
Face the truth: On Windows, there are too many of features (no-checked-iterators, SCL_SECURE, autolinking + _DEBUG) "influencing" ABI compatibility that no "default" solution will suit all needs, even if you are accepting excessive build times.
The only solution I see is to tell the user that is really easy to build the libraries with different options, and show them that it is really that easy (which it is once you found out how to do it).
I agree with this conclusion - better instructions and examples on how to build the variants is the only reasonable solution. Already the build time and disk space is pretty silly. We need a whole stack of worked and tested examples that 'hold the hand' of Windows users - they are not used to this sort of hassle. They need to be told explicitly what is means and what to do when they get a Link error message. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com .
Vladimir Prus wrote:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
There is no autolink default (except for link=static). Autolink links to whatever matches the current compiler options. For VC++ 7.1 or earlier, this means 6 variants: * runtime-link=static, threading=(single|multi), variant=(debug|release) * runtime-link=dynamic, threading=multi, variant=(debug|release) For VC++ 8.0 or later, the variants are four, as the runtime is always multithreaded: * runtime-link=(static|dynamic), threading=multi, variant=(debug|release) The default in the IDE for new projects is, I believe, * runtime-link=dynamic, threading=multi, variant=(debug|release) but VC++8 DLL RTL deployment is somewhat painful so most people immediately switch to static (or forget and later switch to static, cursing quietly, when it's reported to them that the program doesn't start with initialization error 0xC00something.)
Peter Dimov wrote:
Vladimir Prus wrote:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
There is no autolink default (except for link=static).
I have used "autolink default" as a shorthand for "whatever variant is picked by autolink for an IDE project with default options"
Autolink links to whatever matches the current compiler options. For VC++ 7.1 or earlier, this means 6 variants:
* runtime-link=static, threading=(single|multi), variant=(debug|release) * runtime-link=dynamic, threading=multi, variant=(debug|release)
For VC++ 8.0 or later, the variants are four, as the runtime is always multithreaded:
* runtime-link=(static|dynamic), threading=multi, variant=(debug|release)
The default in the IDE for new projects is, I believe,
* runtime-link=dynamic, threading=multi, variant=(debug|release)
Is 'debug' vs 'release' queried at project creation, or two variants are created automatically?
but VC++8 DLL RTL deployment is somewhat painful so most people immediately switch to static (or forget and later switch to static, cursing quietly, when it's reported to them that the program doesn't start with initialization error 0xC00something.)
Hmm. I get an impression that most folks who report issues don't have mt-gd variant, which is dynamic runtime, as far as I can see. And given that autolink defaults to static linking, I suspect that the most reasonable default variant on Windows would be: link=static runtime-link=dynamic threading=multi variant=debug After all, a person who know to switch project to runtime-link=static is likely to realize he wants to rebuild Boost with proper options. And here's a crazy idea -- maybe the autolink can output the message saying that Boost.Build option it assumes? It has this information anyway. - Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG Vladimir Prus wrote:
Peter Dimov wrote:
The default in the IDE for new projects is, I believe,
* runtime-link=dynamic, threading=multi, variant=(debug|release)
Is 'debug' vs 'release' queried at project creation, or two variants are created automatically?
Two variants are created automatically. In Christ, Steven Watanabe
Peter Dimov wrote:
* runtime-link=dynamic, threading=multi, variant=(debug|release)
but VC++8 DLL RTL deployment is somewhat painful so most people immediately switch to static (or forget and later switch to static, cursing quietly, when it's reported to them that the program doesn't start with initialization error 0xC00something.)
Peter, just to clarify -- when switching to static runtime, do folks generally use static libraries, as opposed to DLLs? IIRC, DLLs with static runtime is not very good idea. - Volodya
Vladimir Prus wrote:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
I have always felt that all the possibilities should be built by default. Then all you have to do is document well how to build any subset of the complete set of libraries for a given non-header only Boost library.
2009/4/8 Edward Diener <eldiener@tropicsoft.com>
Vladimir Prus wrote:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
From getting started page, I read: "The option “*--build-type=complete*” causes bjam to build all supported variants of the libraries. For instructions on how to build only specific variants, please ask on the Boost.Build mailing
list<http://www.boost.org/more/mailing_lists.htm#jamboost> . Now, searching the mail-list is quite time-consuming (in my experience), so I think it would be better to give a bunch of examples up-front to the user, so that he/she doesn't need to bother about learning the syntax of bjam or hunt down how to specify the basic options. <Suggestion> "The option “*--build-type=complete*” causes bjam to build all supported variants of -ALL- the libraries. If you intend to use only one or a few libraries, you can improve compilation time by specifying them on the command line:
bjam --with-thread --with-filesystem link=static threading=multi stage
Note the additional options 'link=static' and 'threading=multi'. This instructs the build process to create only static libraries with thread support enabled, which is a reasonable default for most windows executables. There is however one more option of importance; which version of the runtime library you want the boost libraries to use. bjam --with-thread --with-filesystem link=static threading=multi runtime-link=shared stage Here we added the option 'runtime-link=shared', which is the bjam equivalent of the IDE's Runtime Library property (located in Code Generation/Runtime library). If your IDE project has this property set to 'Multi-threaded DLL' or Multi-threaded Debug DLL, the above command line should give you compatible libraries. Finally, you may want to build the boost libraries of your choice for 64bit Windows: bjam --with-thread --with-filesystem link=static threading=multi runtime-link=shared address-model=64 stage </Suggestions> Maybe I got some of the details wrong, but I think something along these lines would give users a better chance to get the build right. I've not used boost libraries in dll's so I've no clue on how to specify that, but I guess it should be added. Also, I only have (limited) experience in boost build shipped with boost 1.35, so the command lines above are maybe no longer correct. My 2... /Christian
Vladimir Prus schrieb:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
What I build is usually autolink/mt/debug+release on Windows, and this has been sufficient for all projects in the last years. There might be people who need the DLL libraries, but by default (IMO) the static autolink libraries are good enough. If someone needs the DLLs, he can easily build them, and for most programs using the static libraries is much more convenient. Cheers, Anteru
Vladimir Prus wrote:
Per:
https://svn.boost.org/trac/boost/ticket/2899
we have a problem that the default set of libraries build on Windows does not match autolink defaults, which causes confusion. In that issue, John say that the only sensible solution for Windows is to build all possible variants by default (IIRC, a total of 6). I would like other Windows developers to comment if that is sensible solution. In particular, is it best to build all possible variants that user might need, or build just the variants that autolink needs by default, so that user can build other later.
Note that I can add arbitrary explanation messages into the build process -- both to warn the user that a scary pile of things will be built, and to warn the user that only couple of variants will be built.
Thanks everybody for the feedback. I think that conclusions are: 1. Autolink defaults to static linking, and it's best if default build of Boost match autolink default, so I'll change Jamroot to build static libraries by default on windows. 2. IDE default is: runtime-link=dynamic, threading=multi, variant=(debug|release) and it's good to match IDE too. Therefore, on windows we'll build link=static runtime-link=dynamic threading=multi variant=debug Anybody thinks we should also build link=static runtime-link=dynamic threading=multi variant=release ? It seems reasonable if IDE creates release variant as well. However, if many users switch to static runtime anyway, maybe we should not waste time building two variants by default if user will switch away to something else. - Volodya
Vladimir Prus wrote:
Thanks everybody for the feedback. I think that conclusions are:
1. Autolink defaults to static linking, and it's best if default build of Boost match autolink default, so I'll change Jamroot to build static libraries by default on windows.
I understood it differently: Autolink doesn't default to anything, but simply does what is specified by the linker options. If my understanding is correct, the statement "Autolink defaults to..." is at least misleading.
2. IDE default is:
runtime-link=dynamic, threading=multi, variant=(debug|release)
and it's good to match IDE too. Therefore, on windows we'll build
link=static runtime-link=dynamic threading=multi variant=debug
When the IDE defaults to both debug and release, how can you conclude "THEREFORE we'll build only debug"? That said, I think it's a good idea to not build the release variant by default, because of the SCL_SECURE issue.
Anybody thinks we should also build
link=static runtime-link=dynamic threading=multi variant=release
? It seems reasonable if IDE creates release variant as well.
I just verified that the IDE creates release by default as well. However, the default compiler and linker options of the release variant are not suitable for really releasing something built with these options. And because SCL_SECURE even leads to ABI incompatibility, it's probably better not to built release by default, but explaining the issues and how to resolve them instead. I had a look at http://www.boost.org/doc/libs/1_38_0/more/getting_started/windows.html#invok... to see how this is currently explained, and it really just says "For instructions on how to build only specific variants, please ask on the Boost.Build mailing list." This is both good and bad. It's good to teach developers that they are allowed to ask questions, but it's bad to teach them to be "careless" about the "accessibility" of documentation. Regards, Thomas
AMDG Thomas Klimpel wrote:
Vladimir Prus wrote:
Thanks everybody for the feedback. I think that conclusions are:
1. Autolink defaults to static linking, and it's best if default build of Boost match autolink default, so I'll change Jamroot to build static libraries by default on windows.
I understood it differently: Autolink doesn't default to anything, but simply does what is specified by the linker options. If my understanding is correct, the statement "Autolink defaults to..." is at least misleading.
Either BOOST_<library name>_DYN_LINK or BOOST_ALL_DYN_LINK must be defined to get dynamic linking. No macro means static linking. In Christ, Steven Watanabe
I understood it differently: Autolink doesn't default to anything, but simply does what is specified by the linker options. If my understanding is correct, the statement "Autolink defaults to..." is at least misleading.
Either BOOST_<library name>_DYN_LINK or BOOST_ALL_DYN_LINK must be defined to get dynamic linking. No macro means static linking.
I thought afterwards that writing "linker options" was not a good idea, because it is macros like _DEBUG, and _DYN_LINK that control the behavior. Still I think that these macros have more influence than just changing the behavior of autolink. So even if the autolink feature would be removed, the macros would still be there (at least that's what I think, I may be wrong). So I still think the statement "Autolink defaults to..." is at least misleading. (It's called "auto...", so no need to "default" to anything.) My main point was that a "default" solution won't really work for Windows, so documentation of the most frequently occurring issues is needed. Just as an example, I now specify <define>_SECURE_SCL=0 on the command invoking bjam when building the release variant. However, I can't tell whether this is the way I'm supposed to solve this issue. When the issue first occurred for me, all I could find was that I should define _SECURE_SCL=0, but no indication of how to define it (it was with boost-build-v1). I ended up modifying the jamfiles themselves, but at least it worked... And before I could even do that, I first had to figure out via debugging that the crashes I was observing were due to an ABI issue caused by _SECURE_SCL. I'm not against a "default" solution, but against pretending that something just works out of the box that simply doesn't. Regards, Thomas
and it's good to match IDE too. Therefore, on windows we'll build
link=static runtime-link=dynamic threading=multi variant=debug
Anybody thinks we should also build
link=static runtime-link=dynamic threading=multi variant=release
?
Yes, I do think so. By default, the IDE creates *both* debug/release configurations, so the default Build should match that. Even though advanced users may want to turn of _SCL_SECURE for release, it's on by default in the IDE, and a compatible boost release should be built by default as well. The typical developer will probably grab Boost, run the default build, get Debug/Release and be able to get work done with that. As soon as he requires _SCL_SECURE to be turned of in Release, dynamic linking or so, the docs should tell him how to accomplish that, but for the sake of getting started quickly the default (static) debug/release versions will be enough. Cheers, Anteru
participants (10)
-
Anteru -
Carlo Medas -
Christian Holmquist -
Edward Diener -
Hansi -
Paul A. Bristow -
Peter Dimov -
Steven Watanabe -
Thomas Klimpel -
Vladimir Prus