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.
OK.
There's a great deal of documentation that would have to change to reflect this as well.
Perhaps... Do you know which docs they might be?
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
Hm, that doesn't sound to me as a rationale, it's more like an excuse. And I suspect the anecdotal evidence about regex is outdated. Currently we usually recommend, in emails, irc, etc., to use dynamic libraries because of memory management problems with static libs. I remember we mention this in some docs, but I don't remember the specific docs at the moment.
There's a further issue with building only one variant under MSVC: it doesn't work!
Interesting definition of "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!
OK, currently the most common questions and gripes I get are: * There's are a bunch of stuff built. Which one do I pick? * Why does it take so long to build? * Why can't I just add a single "-lboost_thread"? And the majority of questions I get are not from developers that are using Boost. But from developers who are using Boost as a third party library. And hence the user is only interested in satisfying the dependency. Developers directly using Boost don't tend to ask the above questions. And just figure out which variants to use on their own. Hence I suspect they will easily figure out how to use the "--build-type=complete" option easily.
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).
So, all the problems you mention above are autolink issues. What problems building more than the dynamic libs on Unix address?
Dynamic *and* static lib, Release *and* Debug, multithreaded, dynamic runtime on Win32 compilers (that's 4 build variants).
A tangent... I can't change the default to vary depending on the compiler used. I can only change it depending on the platform one *runs* on. Which may be inappropriate in a cross-compile context. Could you provide some rationale for why those specific variants? Maybe I'm just confused as to why release and debug, and not just debug if you are trying to satisfy the "default" IDE. (note, I'm not an "IDE" person, at least as IDE's are currently defined by the industry)
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 :-)
The goal is not to build a minimum, but to build *1* and leave building more up to the user. I personally think we've reached the point where the Boost libraries are used generically enough that the variant we build should be the one most likely to be used in the field. So perhaps I'm wrong in thinking that the release/mt/dynamic is the one.
Sorry to be the bearer of the bad news,
I rate this about a 0.5/10 in the scale of bad news I've dealt with in the past few weeks ;-)
PS this is too important and far reaching to be discussed only on boost-build IMO.
I didn't intend for that... I just hit reply instead of reply-all. I guess I didn't see why you included the build list at all in the first place :-\ -- -- 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