Re: [boost] [Boost-build] [1.35] what gets built and installed?

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-12-19 18:52:39

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