Date: Fri, 3 Apr 2009 19:50:11 +0400 From: Dmitry Marakasov <amdmi3@amdmi3.ru> To: Alexander Churanov <alexanderchuranov@gmail.com> Cc: ports@freebsd.org, Jeremy Messenger <mezz7@cox.net>, lwhsu@freebsd.org Subject: Re: Status of devel/boost upgrade Message-ID: <20090403155011.GC60788@hades.panopticon> In-Reply-To: <3cb459ed0904030632x215f1e3n25363903a80b5639@mail.gmail.com> References: <3cb459ed0903270809s2da0fce7i66686a176d369931@mail.gmail.com> <20090331230246.GN1964@hades.panopticon> <op.urotvvn79aq2h7@localhost> <20090401113857.GO1964@hades.panopticon> <3cb459ed0904020821u3051c572l6461274ae7ff118b@mail.gmail.com> <20090402224413.GV1964@hades.panopticon> <3cb459ed0904030632x215f1e3n25363903a80b5639@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Alexander Churanov (alexanderchuranov@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.
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.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090403155011.GC60788>