[liboping] Hacked build config of liboping
Soren A
wetware.interrupt at yahoo.com
Tue Jan 29 10:40:12 CET 2008
Hello Florian, all:
A proper patch is ready now ...* (see below)
Florian Forster <octo at ...> previously wrote:
> Hi Soren,
>
> thanks for your changes :)
Thanks for your fast reply :).
{snip}
> [Note to the ML-users: In a later mail he writes he forgot the
> URL which is <http://intrepid.perlmonk.org/rwbconfigs/>.]
> I'm aware of that - it's the reason I haven't packed another
> release yet.
> I was going to disable the automatic build of the Perl bindings.
> That way users could build the bindings (after installing the
> library) if they need them. However, I'm not even sure if I
> should ship the Perl bindings with the library - imho they are
> two different projects.
It's true, but then again not unprecedented to do it this way; I
can immediately recollect that the Image::Magick Perl module ships
as a sub-component of imagemagick, for example. I wasn't totally
surprised to see that you'd included it, therefore. I was
*impressed* however to see how you'd tried to integrate the action
of `perl Makefile.PL' into the overall pkg build; even if you
didn't get it smoothly working yet, it was bold :-).
> What you're doing is that you link the Perl module statically if
> you think you're in the liboping source tree. For one, I'd
> prefer if that information was given explicitly to the
> Makefile.PL by the autotools, e. g. by passing WITHIN_DIST=1 or
> something like that.
That's a good idea.
> The other thing that bugs me is that the Perl module is linked
> statically although the shared object is available, so that you
> need to rebuild the Perl module every time the library changes.
Absolutely right, of course (and I am so glad that you understood
what was happening just by reading the code ... I wasn't sure how
much I was going to need to explain). Yes, there are drawbacks for
sure, and if this was included in the liboping distro, maybe
requiring a special flag to configure would be the most desirable
thing. Something like
$ ./configure --perl-build-static
to tell it that we really want to create the Perl extension module
using an (un-installed) static instance of the library from the src
kit instead of linking against an installed liboping.
> All in all I think I'll just keep the two things separate. If
> you (or Sebastian?) think this is a bad move, please let me know
> - maybe you see some advantage of that which I missed.
I'll be doing some more thinking about it. I'm just glad if I
could contribute something that was of *any* interest.
> Regards,
> -octo
> P. S.: Please send a CC of future mails to the mailing list. The
> easiest way to do this is by group-replying to this email.
Done.
*I've created a patch file to be applied with
$ patch -p1 <liboping-Perl.patch
That simplifies the testing of the changes (when applied to the
source tree obtained by doing `git clone
git://git.verplant.org/liboping.git.'
The patch is in the site cited earlier, alongside the CPAN dist
-style tarball I rolled:
http://intrepid.perlmonk.org/rwbconfigs/liboping-Perl.patch
Regards,
Soren Andersen
P.S. Now tested on a second GNU/Linux system: Linux
2.6.15-gentoo-r1
--
"All unattended children will be given espresso and a free kitten."
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
More information about the liboping
mailing list