A-B future

[mohawk2]

@devel-chm raised these excellent points on this other issue (https://github.com/Perl5-Alien/Perl5-Alien-Documents/issues/4#issuecomment-53967860):

I do think that some structural changes will need to optimize AB for Alien2 capabilities however, the fact that it is a build-on framework means that we can make the changes and fairly simply port existing AB users to A2B. For most purposes, I hope that the "fixed" API still starts from the same beginnings. It just works a lot better making things work cross-platform.

Here are some of the pieces we have (already!) to work with. This is a list of my thoughts which may differ from others ideas along the same lines:

(1) Use PkgConfig to standardize communication of platform installation information and capabilities. NOTE: we will need to deal with issues of whether and where the pkg-config files would be but it makes sense to me that the vocabulary should still be the same whether or not a distribution pkg-config is present.

(2) AB is improving incrementally but I think a simple refactoring to make the operation symmetric across platforms would really help

(3) I think we should think about using EUMM as the dominant build process for AB (vs MB) for a number of reasons. EUMM is the defacto build process for perl and is supported across ALL perl platforms. Many/all external dependencies actually need the usual make/gcc/... environment to build so a AB module would need a make, a shell, and a compile environment to do more than detect. We could support a set of MB tools or modules to enable platform users to obtain a make+shell+cc build environment and then go straight make from there. Personally, I think the pure perl build tool is the most elegant solution but MB seems to be losing momentum---in part because it is a thankless job to implement EUMM and make in perl. Lots of more enjoyable and interesting things to program out there!

(4) PDL has a large number of external dependencies that could be used as use cases with which to develop this functionality along with a number of motivated developers.

[plicease]

https://metacpan.org/pod/release/PLICEASE/Alien-Base-0.004_03/lib/Alien/Base.pm

There is a problem with DESTDIR + MSWin32, so I opened #66. As mentioned in that bug I don't feel it is a blocker, but ought to be tracked and corrected when possible. Tested this dev release by

1. installing Alien::Base and Acme modules on MSWin32 and Linux, which is where I noticed #66
2. travis-ci.org build
3. OBS build of Alien::Base, Acme modules and Alien::LibGumbo

[plicease]

https://metacpan.org/pod/release/PLICEASE/Alien-Base-0.004_04/lib/Alien/Base.pm

Noted an issue with blib detection, which manifested itself on cygwin see #67 for details.

[plicease]

@mohawk2 one feature for Alien / FFI integration that I think would be useful is some compilerless detection, ie verifying the existence and viability of a library when a compiler is not available so that it can be used by an FFI module. Not exactly sure on the how for this. I was able to achieve this in Alien::Libarchive by separating the installer from the MB class at the cost of some complexity.

[mohawk2]

@plicease, do you think it would be useful to incorporate and encapsulate the code you made for A::La into A::B? If so, we should discuss the design and be sure @jberger is content.

[mohawk2]

In the meantime, I am keen for us to get to a point where we have a dev release that we don't want to change any further and passes a decent cross-section (or all of) the CPAN testers' network. How close are we?

[plicease]

@mohawk2

I think at the moment I am more comfortable with drawing lessons from the A::La work that I did. I was in the process of generalizing it, but it is quite a different approach, using roles etc. AB is more of a recipe approach, which is a much easier but less powerful in some respects.

The dev releases look really good on cpantesters, and in my own testing (OBS, travis and manually). I'd like to do one more dev release with the last set of fixes that just got merged, and if it looks good in a couple of days then we go ahead and do a production release. Does anyone disagree with this strategy?

Arguments for:

1. The actual interface hasn't changed radically so risk that we've made (new) design mistakes is lowish
2. There are a lot of bug fixes (esp in windows) in this version and windows / autoconf support
3. We can start pushing Alien:: authors to use static libs which will improve reliability on most platforms

Against:

1. That we've introduced some nasty bugs?
2. Doing a production release will probably reveal even more windows bugs... (though I think they will be hard to flush out without doing a proper production release)

[plicease]

https://metacpan.org/pod/release/PLICEASE/Alien-Base-0.004_05/lib/Alien/Base.pm

In light of the last two comments I propose that this be a RC.

[mohawk2]

I would say it seems RC-worthy. I am not aware of AB having worked usefully on Windows previously, so any bugs in that side of things aren't really a regression.

@jberger, your input is sought on making .004_05 be potentially .005.

[plicease]

In my testing I was able to get 0.004_05 and from git Acme::Alien::DontPanic and Acme::Ford::Prefect to install successfully on these platforms:

Cygwin 64 FreeBSD Debian Linux Debian kFreeBSD MSWin32 NetBSD OpenBSD Solaris

I am not able to test OS X.

[plicease]

I see an OS X pass here:

http://217.199.168.174/cgi-bin/cpantestersmatrix.pl?dist=Alien-Base%200.004_05;os=darwin;perl=5.20.0;reports=1

I think if nobody speaks up against, and there are no cpantesters failures, I will send a prod release to CPAN tomorrow morning.

[devel-chm]

If you have a release candidate, I suggest recruiting some Alien::XXX developers who are using the existing AB to update their modules as a final shakeout. Also useful, maybe based on that input, a migration guide.

On Tue, Sep 9, 2014 at 8:41 PM, Graham Ollis notifications@github.com wrote:

https://metacpan.org/pod/release/PLICEASE/Alien-Base-0.004_05/lib/Alien/Base.pm

In light of the last two comments I propose that this be a RC.

— Reply to this email directly or view it on GitHub https://github.com/Perl5-Alien/Alien-Base/issues/43#issuecomment-55057064 .

[plicease]

I went through all the reverse dependencies for Alien::Base. The only one that had an incompatibility with 0.004_05 was Alien::ffmpeg, which I have already sent a PR, you can see it here:

https://github.com/Getty/p5-alien-ffmpeg/pull/1

About half of the Alien::Base reverse dependencies failed to install, but checking against the cpan testers results in each case it appears that this is an existing problem, and not an issue with the new version. I have engaged with a few Alien::Base authors along the way.

[plicease]

What do people think about getting an AB mailing list? IRC might be good too although I don't use IRC. This has been a good discussion of ideas, but this gh issue is getting a little long winded.

[zmughal]

Yes, I agree on having a mailing list. Can we make one on perl.org? Should I go poke around and see how that can be done?

If we went with IRC, then we need logging, IMO. Currently we've been discussing most Alien things in the #pdl channel on irc.perl.org. That is logged.

I prefer a mailing list in this case.

[plicease]

@zmughal if you can poke perl.org to see if we can get a mailing list that would be great.

[plicease]

Agree about logging, also would like to see any mailing list be configured to have an archive.

[zmughal]

OK, I've sent an e-mail.

[zmughal]

The reply I got:

We suggest you use Google Groups.

@jberger Would you like to create a Perl5-Alien Google Group? We can then submit it to be listed at lists.perl.org (And some people are using CPAN Meta for it. https://github.com/CPAN-API/metacpan-web/issues/1235 may expose that if we use it.).

[jberger]

Regarding Alien::La moving to A::B, A::B is not meant to be a magic bullet. I'm glad to see it progress and I hope for it to work in most cases, but its essence is to be easy to release a useful module. There is no benefit to migrating to A::B unless it would then better provide the library (i.e. if it works, don't fix it).

[jberger]

Regarding generic discussion of a release (and other future considerations), lets move that over to the new list.

[jberger]

Also, @mohawk2 @devel-chm @plicease @zmughal please join the list and I will then add you as ops

[plicease]

I am added