Status of devel/boost upgrade

[Jeremy Messenger]

On Fri, 03 Apr 2009 09:50:11 -0600, Dmitry Marakasov <amdmi3 at amdmi3.ru>  
wrote:

> * Alexander Churanov (alexanderchuranov at gmail.com) wrote:
>
>> There are 95 libraries in boost.
>
> Woo, that's sure too many.
>
>> Let me explain that:
>> Boost has source-only libraries and separately-compiled libraries.
>> Source-only libraries consist of header files only and do not require
>> any compilation at all. Separately-compiled libraries consist of BOTH
>> header files and shared library objects.
>
> Yeah, I know that.
>
>> I often use source-libraries only. For example currently in a project
>> at work  I use "interprocess", "function", "smart ptr". Neither of
>> them requires compilation. Hence the idea.
>
> There sure is a point. However I still don't like tearing the port in
> half based on some unpractical criteria. It resembles most linux
> distros' stupid way of splitting includes into separate packages
> too much :)
>
> If you devel with boost, you probably will need some of shared libraries
> sooner or later, so you will probably install the whole boost once to
> not waste time for lacking components later. What's for the users, I can
> see theoretical advantage - if many ports depend on header libs only,
> this part of boost will be installed fast without compiling anything.
> However, from my experience most ports still depend on shared libs, so
> this will not really bring anything good. Can you provide any statistics
> on how many ports will benefit of that?
>
>> So then the list of options is as follows:
>>
>> 1) "jam", "source-libs", "compiled-libs" (or "shared-libs"),
>> "python-libs" and "docs"
>> 2) "jam", "libs", "python-libs" and "docs"
>> 3) "jam", "docs" and 95 ports more :-)
>
> I'm for 2, but not against 1 if it brings more advantages than
> inconvenience.

I agree with what Dmitry has said. I vote for #2.

Cheers,
Mezz

> And there's another option between 1 and 3.
> 4) "jam", "docs", "source-libs" and N more, where N is up to number of
> shared libs installed by boost. For 1.37 there are 19, but some
> small/related ones may be merged (maybe math? for example, ubuntu
> has 13 packages for separate libs for boost 1.35 including python).
>
> It seem to be more logical than just source/shared ports as it will
> really fasten compilation by not building unneeded parts of boost,
> it's consistent with boost-python separation, it's somewhat transparent
> from the point of library names (i.e. if I want ${libname} I should use
> boost-${libname} if it exists, else just boost-other or how-do-we-name-
> it).
>
> The statistics on what ports use which boost libs, and build times for
> separate boost libs will really be useful.
>



-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org