From: Andreas Klöckner (lists_at_[hidden])
Date: 2008-06-16 13:01:47
(I've cc'ed the ublas list. Hope you don't mind.)
On Montag 16 Juni 2008, you wrote:
> I'm a gentoo user and so I created a simple .ebuild to allow the seamless
> installation of your snapshot into my computer. Unfortunately it wouldn't
> work correctly since the provided 'configure' script does not adhere to the
> regular autotools parameters that the ebuild requires, so I created the
> needed scripts for automake, autoconf,etc and pointed by .ebuild to used
> them. You can find the 'new' package snapshot at
First of all, thanks for going through all the effort. However, I'm sorry to
say that, apart from supporting pkg-config, I'm not a fan of automake or
autoconf, and I believe it's overkill for a header-only package. In
particular, I'm not looking forward to maintaining a Makefile.am in *every*
directory, when a `find -name '*.hpp' -o -name '*.h'` has the same effect. If
you could tell me what went wrong with the initial ebuild, I'd much rather
fix my (admittedly kludgey, but serviceable) configure/Makefile combo.
> In there I created all the files to easily use the bindings, which will
> normally get installed at /usr/include/boost-numeric-bindings along with
> the .pc file for pkg-config at /usr/lib/pkgconfig/ .
This is neat. Maybe there's a way we can have that without having to buy all
> I'm not sure if it would be easier to use bjam to create a better
> 'configure' script, what do you say?
I've also gotten nothing but pain out of bjam, so I'm trying to stear well
clear of it. If (when?) the bindings become part of boost, they will however
be installed/tested using bjam. Thomas Klimpel is (I think) working on proper
Jamfiles for the bindings. Once that matures, I'm much more likely to follow
him to keep my upstream delta small.
> I also recommend to change the package name to boost-numeric-bindings,
> instead of just boost-bindings.
That's sensible. I'll do that with the next release.
> One thing I could also do, if you prefer to
> keep the bjam file, would be to create a patch with the autotools files
> that could be applied to your package.
If you find that you can't live without the auto* stuff, this may be your best
option. But I'd rather find a solution with which both you and I can live.
> I also didn't put the documentation into the installation process, but it
> can be added easily later on.
> Another important issue is related to missing 'inline' keywords from the
> umfpack_overloads.hpp file, reported long ago by Anton Kuut:
Ok, fixed. Is in git, will be in next release.