For where pkg-config doesn't work

[Graham Ollis]

One of my bullet points here:

https://github.com/Perl5-Alien/Perl5-Alien-Documents/issues/2#issuecomment-52748503

was "less dependence on pkg-config".  We are now using PkgConfig.pm where pkg-config is not available, which improves things a lot.

A related issue is packages that don't provide pkg-config.

Some packages just expect you to know -lfoo will work.  libarchive actually provides a .pc file everywhere, except for FreeBSD, where it is part of the operating system and you are expected to simply know that -larchive will work.

Some packages provide a foo-config program that works like pkg-config.

It would be good to support both of these.

For the former, I think supporting something like this:

  alien_guess_flags => { cflags => '', libs => '-lfoo' },

it could be an array ref to try different combinations.  It would also be good to have something to test for so maybe 

  alien_test_program => <<EOM;

#include <foo.h>

int

main(int argc, char *argv[])

{

  printf("version = '%s'", foo_version());

  return 0;

}

EOM

This could be used with either alien_guess_flags or pkg-config.  If the version can be determined by the test program then it can print some pattern that AB will understand as being the version and can use that for version requirements.

[Zakariyya Mughal]

I do like this idea. I had an issue with this with my Alien dist
Alien::UDUNITS2[*]. It does not use pkg-config, but because Alien::Base
searches for dynamic libraries to find the linker flags, it still works
fine. Well, just on Unix systems. Turns out that the Windows build for
UDUNITS-2 only builds static libraries even after trying to get it to do
otherwise with configure flags. All I get on Windows is an archive file
(.a) and a libtool file (.la).

Because Alien::Base only looks for dynamic libraries, libs() for
Alien::UDUNITS2 is empty on Windows. My current solution is to override
the libs() method and provide a set of working flags. I would like this
to just be a temporary measure just to get a release to CPAN and have
Alien::Base v0.005's features tested on Windows.

It may be worth looking into the libtool .la file if it is available.
That has much of the same information that we want from pkg-config.

For handling the compilation step of the proposed change, we could use
Devel::CheckLib or ExtUtils::CChecker. With a couple of my Alien
packages, on mohawk's advice, I have been using Inline::C to test that
the install can actually be compiled and linked to Perl
(Alien::Leptonica and Alien::UDUNITS2 do this).

Finally, good news! I was able to get Alien::UDUNITS2 up to CPAN and I'm
waiting on reports from Windows. It works on my Windows 7 VM. I asked
mohawk to test it via IRC, but there appears to be an issue with
installing File::chdir. I believe this Windows box is having the same
issue: <http://www.cpantesters.org/cpan/report/d9c6d1e6-6c43-1014-a24e-3d198ac59954>.

Cheers,
- Zaki Mughal

[*]: <https://github.com/zmughal/p5-Alien-UDUNITS2>.



>
> --
> You received this message because you are subscribed to the Google Groups "Perl5-Alien" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to perl5-alien...@googlegroups.com.
> To post to this group, send email to perl5...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/perl5-alien/886dcd77-809e-4d25-93c8-29c10bdcc6ed%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Graham Ollis]

On Tuesday, September 16, 2014 1:22:20 AM UTC-4, Zakariyya Mughal wrote:

Because Alien::Base only looks for dynamic libraries, libs() for
Alien::UDUNITS2 is empty on Windows. My current solution is to override
the libs() method and provide a set of working flags. I would like this
to just be a temporary measure just to get a release to CPAN and have
Alien::Base v0.005's features tested on Windows.

Can we change Alien::Base to look for .a and then fallback on .so?

  

It may be worth looking into the libtool .la file if it is available.
That has much of the same information that we want from pkg-config.

I don't think the .la file will be at all hard to parse.  Interesting:

https://www.flameeyes.eu/autotools-mythbuster/libtool/lafiles.html

It would be good to default to static where possible.

 

For handling the compilation step of the proposed change, we could use
Devel::CheckLib or ExtUtils::CChecker. With a couple of my Alien
packages, on mohawk's advice, I have been using Inline::C to test that
the install can actually be compiled and linked to Perl
(Alien::Leptonica and Alien::UDUNITS2 do this).

I really like the interface for ExtUtils::CChecker.  The authors responsiveness to requests has been a little mixed.  We can also use ExtUtils::CBuilder, which is in core 5.10+.

 

Finally, good news! I was able to get Alien::UDUNITS2 up to CPAN and I'm
waiting on reports from Windows. It works on my Windows 7 VM. I asked
mohawk to test it via IRC, but there appears to be an issue with
installing File::chdir. I believe this Windows box is having the same
issue: <http://www.cpantesters.org/cpan/report/d9c6d1e6-6c43-1014-a24e-3d198ac59954>.

I haven't had trouble installing File::chdir on my Windows.  One alternative is File::pushd, which does more or less the same thing with a different interface.

[Zakariyya Mughal]

On 2014-09-16 at 03:31:20 -0700, Graham Ollis wrote:
>
>
> On Tuesday, September 16, 2014 1:22:20 AM UTC-4, Zakariyya Mughal wrote:
>
> Because Alien::Base only looks for dynamic libraries, libs() for
> > Alien::UDUNITS2 is empty on Windows. My current solution is to override
> > the libs() method and provide a set of working flags. I would like this
> > to just be a temporary measure just to get a release to CPAN and have
> > Alien::Base v0.005's features tested on Windows.
>
>
> Can we change Alien::Base to look for .a and then fallback on .so?
>
>
> > It may be worth looking into the libtool .la file if it is available.
> > That has much of the same information that we want from pkg-config.
> >
>
> I don't think the .la file will be at all hard to parse. Interesting:
>
> https://www.flameeyes.eu/autotools-mythbuster/libtool/lafiles.html
>
> It would be good to default to static where possible.

Yes to both for me (choose .a over .so and static over dynamic linking).
There seem to be more advantages to these than disadvantages. The only
time I would prefer dynamic linking is for using LD_PRELOAD and
debugging.

Perhaps we could use something like:

libs():
if( $ENV{PERL_ALIEN_FOO_LIBS} eq 'dynamic' ) {
return $self->_dynamic_libs_flags();
}
return $self->_static_libs_flags(); # default to static
_dynamic_libs_flags(): "-L/path/to/share/dynamic -lfoo" # link to libfoo.so
_static_libs_flags() : "-L/path/to/share/lib -lfoo" # link to libfoo.a

This way, when Foo::XS is installed, the user can control how they want
to link. All they need to know is that Foo::XS uses Alien::Foo. This
will be an option for power users that may need to debug Foo::XS and is
easier than going in and editing the Perl build script.

> > For handling the compilation step of the proposed change, we could use
> > Devel::CheckLib or ExtUtils::CChecker. With a couple of my Alien
> > packages, on mohawk's advice, I have been using Inline::C to test that
> > the install can actually be compiled and linked to Perl
> > (Alien::Leptonica and Alien::UDUNITS2 do this).
> >
>
> I really like the interface for ExtUtils::CChecker. The authors
> responsiveness to requests has been a little mixed. We can also use
> ExtUtils::CBuilder, which is in core 5.10+.
>

I was looking over the docs again and I saw alien_provides_cflags and
alien_provides_libs. These probably fit my need better for the case of a
missing pkg-config. I'll have to test it later.

If we also use the .la & .a files to find the flags, then a potential
class Alien::Base::Libtool or an updated alien_find_lib_paths() will
give me everything I need and I won't need to override libs().

Perhaps we need a cookbook to distill this information for Alien::
module authors in the form of Problem / Solution?

>
> > Finally, good news! I was able to get Alien::UDUNITS2 up to CPAN and I'm
> > waiting on reports from Windows. It works on my Windows 7 VM. I asked
> > mohawk to test it via IRC, but there appears to be an issue with
> > installing File::chdir. I believe this Windows box is having the same
> > issue: <
> > http://www.cpantesters.org/cpan/report/d9c6d1e6-6c43-1014-a24e-3d198ac59954>.
> >
> >
>
> I haven't had trouble installing File::chdir on my Windows. One
> alternative is File::pushd, which does more or less the same thing with a
> different interface.

I haven't had any trouble with it either. I saw this issue that Joel
answered from 2 years ago: <https://github.com/Perl5-Alien/Alien-Base/issues/19>
which led to a patch to Perl. Could that be the problem, mohawk? We may
need to put a minimum version of 3.40 on Cwd to get that patch (or get
File::chdir to do so (currently File::chdir has Cwd => 3.16))[+]

[*]: alien_provides_cflags option: <https://metacpan.org/pod/distribution/Alien-Base/lib/Alien/Base/ModuleBuild/API.pod#alien_provides_cflags>
[+]: Changelog for Cwd that shows where the patch "Cwd::fast_abs_path's
untaint should allow for multiline directories (Joel Berger)" occurs:
<https://github.com/tsee/PathTools/blob/c6edf1986ccc855834a5ca09d2b3aced8b0d3c35/Changes#L20>

[mohawk]

I'm against using env vars to control these things. With a view towards FFI, I'd like there to be methods to set loading of the dynamic library (unless that can also be done with a static lib?).

[Graham Ollis]

On Tuesday, September 16, 2014 1:14:11 PM UTC-4, Zakariyya Mughal wrote:

Perhaps we need a cookbook to distill this information for Alien::
module authors in the form of Problem / Solution?

This is definitely something helpful missing in the documentation.  Either a FAQ or a common patterns to packages guide or something. 

[Graham Ollis]

On Tuesday, September 16, 2014 1:14:11 PM UTC-4, Zakariyya Mughal wrote:

Perhaps we could use something like:

    libs():
          if( $ENV{PERL_ALIEN_FOO_LIBS} eq 'dynamic' ) {
              return $self->_dynamic_libs_flags();
          }
          return $self->_static_libs_flags(); # default to static
    _dynamic_libs_flags(): "-L/path/to/share/dynamic -lfoo" # link to libfoo.so
    _static_libs_flags() : "-L/path/to/share/lib -lfoo"     # link to libfoo.a

This way, when Foo::XS is installed, the user can control how they want
to link. All they need to know is that Foo::XS uses Alien::Foo. This
will be an option for power users that may need to debug Foo::XS and is
easier than going in and editing the Perl build script.

I wouldn't appose an option, but I tend to this giving the XS author too much control.  It might sound a little heavy handed, but I think that maybe if both static and dynamic are available, we should be using the static for XS and dynamic for FFI.

[Zakariyya Mughal]

Isn't dynamic_libs() enough to support FFI, no?

Cheers,
- Zaki Mughal

> --
> You received this message because you are subscribed to the Google Groups "Perl5-Alien" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to perl5-alien...@googlegroups.com.
> To post to this group, send email to perl5...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/perl5-alien/ce48ad18-f620-43f2-90c7-3ceb8659b9b1%40googlegroups.com.

[Zakariyya Mughal]

I understand. I was just giving an option for the installing user rather
than the Alien:: author. I'm going to just say YAGNI to that level of
configurability for now. We'll see if someone *really* wants to have
things like dynamic linking or other build options like debugging
symbols when the time comes.

Sounds like the next steps are:
1) parse libtool .la files if there is not a pkg-config,
2) search for .a files for manually detected linker flags, and
3) write a cookbook-style FAQ for common packaging issues.

Should I put in feature requests for those?

Cheers,
- Zaki Mughal

[Graham Ollis]

On Tuesday, September 16, 2014 3:47:10 PM UTC-4, Zakariyya Mughal wrote:

> I wouldn't appose an option, but I tend to this giving the XS author too
> much control.  It might sound a little heavy handed, but I think that maybe
> if both static and dynamic are available, we should be using the static for
> XS and dynamic for FFI.

I understand. I was just giving an option for the installing user rather
than the Alien:: author. I'm going to just say YAGNI to that level of
configurability for now. We'll see if someone *really* wants to have
things like dynamic linking or other build options like debugging
symbols when the time comes.

Agree, if it helps someone install a real life package that otherwise wouldn't work then it should go in.  I'm just not in favor of options that are in search of a problem.

 

Sounds like the next steps are:
  1) parse libtool .la files if there is not a pkg-config,
  2) search for .a files for manually detected linker flags, and
  3) write a cookbook-style FAQ for common packaging issues.

Yes, I think so.  Also, something to think about: there are some packages that don't have .la or .pc files either :P