Boost in sage: proper inclusion?

[Julien Puydt]

Hi,

I raise the question of boost in sage because :

(1) of the recent "PolyBoRi requires boost library" thread on this
mailing-list ;

(2) because sage 5.0 has a boost_cropped spkg, whose SPKG.txt says it
was obtained by taking the sources out of polybori's, which means :
(i) it wasn't a proper packaging from upstream ;
(ii) it's not clear which parts of boost it contains : apt-cache search
libboost |grep 1.49.0 |wc -l says 21 on my box, and I don't have
everything installed -- for example I don't have the unit-test part
which is the subject of the other thread, so "boost" is perhaps too
generic, especially since it's "boost-from-polybori".


The second point has bothered me for quite some time already, so
with the first in the air, it might be time to ask : wouldn't it be
worth to have a proper boost spkg, which would contain the needed
frameworks, coming from upstream?

I know asking for the inclusion of something in sage might be
surprising coming from me, but I prefer a clean and clear from-upstream
spkg than patches left and right.

Snark on #sagemath

[Jeroen Demeyer]

On 2012-05-18 10:14, Julien Puydt wrote:
> The second point has bothered me for quite some time already, so
> with the first in the air, it might be time to ask : wouldn't it be
> worth to have a proper boost spkg, which would contain the needed
> frameworks, coming from upstream?

In principle I have nothing against including boost, but you should know
that it takes close to 50MB, which would make it the *largest* package
in Sage, apart from the Sage library itself.

[Julien Puydt]

Le vendredi 18 mai, Jeroen Demeyer a écrit:

Well, the upstream boost_1_49_0.tar.bz2 is indeed about 50M, but :

- it contains all the documentation ;

- it contains the tools to build a few things (notably the
documentation) ;

- it contains all of boost, while the only thing using boost in sage,
polybori, probably only uses only parts of it (which ones? Probably
the unit test and the python).

In fact, if you take the upstream tarball, and keep only the boost/
directory, you get :
$ ls -hl boost_1_49_0_only_boost_dir.tar.bz2
-rw-r--r-- 1 jpuydt jpuydt 5,4M mai 18 12:08
boost_1_49_0_only_boost_dir.tar.bz2

As boost is mostly a pure-header library, this is probably enough (the
current boost_cropped spkg-install only uses 'cp' -- no compilation,
so it's not unreasonable).

Would an SPKG.txt stating : "Packaged by taking upstream's full
boost_1_49_0.tar.bz2 and keeping only the boost/ directory." and an
spkg-install just doing cp be ok?

Snark on #sagemath

PS: Perhaps I can compile enough of sage-5.0 to see if that would fly
with polybori... but I'm not sure. I find it annoying to propose things
I can't test, but I don't think I can do better at the moment :-(

[Volker Braun]

I just had a look at boost, if we delete the documentation then it is 25MB. Without documentation and tests it is 15MB, though I'd rather have the tests included.

Although most of boost is headers, some libraries need to be compiled. The biggest question is probably if we want to build boost/Python, which is roughly the inverse of Cython: write Python objects in C++. 

Boost/Math/Special functions might be useful to avoid the shortcomings of the libc implementations on some platforms.

[Julien Puydt]

Le vendredi 18 mai, Volker Braun a écrit:

The current boost_cropped contains headers, nothing compiled.

My proposition is mostly to replace a bunch of headers described by the
rather cryptic "Split boost sources off of polybori.spkg" (Are they all
of boost-1.34.1 upstream? Only a part? Which part? Which version of the
polybori spkg was it?), by a bunch of headers taken directly from
upstream with an explicit list of what was taken "The package contains
the following directories taken from boost version 1.49.0 : ...".

Notice that boost is in sage for polybori, and polybori is compiled
with no boost-python support (from custom.py, in the current polybori
spkg):
HAVE_PYTHON_EXTENSION=False
EXTERNAL_PYTHON_EXTENSION=True

Snark on #sagemath

[Volker Braun]

I just tried to build the newest polymake (2.12.rc3) and it doesn't compile because it uses some bit of boost that is not in our cropped boost. It has a configure switch to specify a particular boost, but since it also uses gmp/mpfr it still picks up our cropped boost. And the cropped boost is not compatible with the full boost in Fedora, so it craps out with strange error messages. I think we are just shooting ourselves in the foot by shipping a partial boost library.