From: Nuno Sucena Almeida (slug_at_[hidden])
Date: 2008-06-18 14:52:20
On Monday 16 June 2008 01:01:47 pm Andreas Klöckner wrote:
> 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.
I checked your python script before I started to create the auto* files and
found it clever to use the output of find, since it also shows the correct
path where to put the headers. If you take a look at each Makefile.am, it
uses a similar trick, for example for amos:
so in theory we would only need to add a new Makefile.am to a new binding and
not if there's more headers added later to the bindings that already exist.
> If you could tell me what went wrong with the initial ebuild, I'd much
> rather fix my (admittedly kludgey, but serviceable) configure/Makefile
The problem is the use of the --prefix parameter, which in the case of gentoo
uses it for 'compilation' and installation into a sandbox, which is then
copied to the final destination directory if everything goes well. By the
way, I also noticed the same issue with your PyUblas package.
> This is neat. Maybe there's a way we can have that without having to buy
> all the autotools.
That would be nice and probably easy since we just need to replace a few
strings inside the .pc.in file, but the autotools scripts have an easy job to
do for this particular package. In that respect, probably it would not make
it terrible portable, since a configure --prefix might be different from a
make installdir. I don't know if any other (linux/etc) distribution would
have the same requirements.
> 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.
Did Thomas made his work public? I would probably prefer to use it then :)
> > 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