|
|
Ublas : |
From: Andreas Klöckner (lists_at_[hidden])
Date: 2008-06-19 11:42:50
Hi Nuno,
On Mittwoch 18 Juni 2008, Nuno Sucena Almeida wrote:
> 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:
> library_includedir=$(pkgincludedir)/$(BNBD)/amos
> library_include_HEADERS=*.h *.hpp
>
> 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.
That's still (presently) 26 Makefiles to maintain, as opposed to one. Plus all
the litter that automake spews all over your source tree. As I said, I'm not
a fan, especially given that all the install really has to accomplish is copy
a bunch of headers from A to B.
> > 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.
>
> 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.
First off, PyUblas is different because its configure flat out
*ignores* --prefix (--help says so) and simply installs into the Python tree
that it's run with. Your distribution likely already has a scheme in place to
distribute Python distutils packages--that's what you should use in this
case.
I still don't understand what goes wrong between my configure and the ebuild.
The script should not have a problem with that. Can you post an actual error
message? From your later comments, I'm assuming that gentoo somehow tries to
override make variables after configure. This could be replicated if I knew
what variables it tries to override.
> > 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.
Hmm, ok. So that would complicate things. Let's focus on getting the thing to
ebuild properly first.
> > 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 :)
Just check the boost sandbox svn. Thomas, would these Jamfiles be of any help
in the separate-installation case? Another issue: The typical user of the
bindings will have bjam, but it's buried somewhere in the boost project tree.
We don't necessarily know where to find it without the user telling us, and
it doesn't get installed by default (I think).
> > > 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.
You can also easily maintain a git branch with (just) your auto* stuff, if you
like.
Andreas