[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