John Maddock wrote:
Rene Rivera wrote:
John Maddock wrote:
If I do a:
bjam stage --toolset=msvc-8.0 --with-regex
Then with 1.35 I don't get any static libraries built, just the dll's. Was this a deliberate change somewhere? It's a problem because the default for auto-linking is to look for static rather than dynamic libraries.
Yes, it was intentional <http://article.gmane.org/gmane.comp.lib.boost.devel/168552>. We also discussed it at one point <http://article.gmane.org/gmane.comp.lib.boost.devel/166847>. I guess we should switch autolink to default to the dynamic libs?
That's actually not possible without changing folks library code: it's a per-library decision which is the default, with the static library being recomended as the default unless there are reasons to choose otherwise. There's a great deal of documentation that would have to change to reflect this as well.
There's also a rationale for why static linking is the default behaviour in our docs here: http://www.boost.org/more/separate_compilation.html#static_or_dynamic
There's a further issue with building only one variant under MSVC: it doesn't work!
By only building a release build, then the only thing that will work "straight out the box" is building a release build of your application against the dll runtime. Debug builds will generate linker errors (can't find the auto-linked library etc), as will builds against the static runtime, this means that Boost will appear totally broken if users try and build the default debug builds that their IDE gives them.
We need to be *very* careful with this, or the complaints will be loud and vociferous!
If the aim is to reduce the number of variants built, then I would suggest:
Dymanic *and* static lib, as Release, multithreaded, dynamic runtime single build on Unix variants (2 build variants). Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic runtime on Win32 compilers (that's 4 build variants).
That's an absolute minimum IMO. Even then we will have to be very careful that our build instructions indicate very clearly how to build the other variants, especially for those msvc users :-)
Sorry to be the bearer of the bad news,
If a user may be permitted to comment, I think John is correct here. It is far better that the boost build take a long time (with a big warning in the build instructions to that effect) but build all of the normally used variants than having it build only Release shared libraries. My guess is that most Boost users are developing for deployment to their users, and many of them will want their apps to be statically linked to Boost libraries, among others, in order to avoid a whole host of issues. I also can't believe that anyone who uses an IDE for development doesn't build Debug versions much more often, and usually by default, than they build Release versions. This is certainly true for MSVC and Xcode users. I think you will get many complaints and spend a lot of time answering the "how do I build static libraries on platform x" and "how do I build debug libraries" posts if you change the default. If you do change the default behavior to build only Release shared libraries, then you need to make it dead simple to build all of the variants. Best regards, Rush