On Fri, 03 Apr 2009 09:50:11 -0600, Dmitry Marakasov <amd...@amdmi3.ru>
wrote:
* Alexander Churanov (alexanderchura...@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.
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
