Build/installation process is installing *.a files and breaking perl installations about alien-svn HOT 7 OPEN

That report is an error in the ExtUtils::MakeMaker test suite. What does it have to do with Alien-SVN? What would Alien-Base do to solve this problem?

from alien-svn.

Are you saying that a distro that installs *.a files without probably intending to is working in a well-behaved way?

from alien-svn.

Let's back up. If you think something's wrong, it probably is. I only have a vague idea of what a .a file is, so you're going to have to explain what Alien::SVN is doing naughty in some more detail. Alien::SVN is a thin wrapper around the Subversion source and uses their build process. Explanations would be great. A pull request would be even better. We really need help from someone who understands all that.

I'm also totally open to replacing Alien::SVN's custom build code with Alien::Base. It looks like it'll do everything Alien::SVN does and more.

As for MakeMaker, I understand that's what pointed you at the problem in Alien::SVN, and vaguely understand how Alien::SVN might break makeaperl... but if Alien::SVN can break their tests, they need to rethink how that test works.

from alien-svn.

A .a file is an archive library containing object files, useful for static linking. A .so file is the rough equivalent for dynamic loading.

XS libraries, either static or dynamic, are distinguished by having a function "boot_library__name__mangled". EUMM's "makeaperl" functionality relies on all .a files in the various arch/auto directories being valid XS libraries.

It's not the tests that are being broken by A-SVN, it's the actual perl installation. However, since the tests for EUMM's XS functionality were until the latest dev releases a bit, um, minimal, that fact was hidden and thus distros like this one and others have unintentionally deposited non-XS .a files in many innocent perl users' installations.

from alien-svn.

What are the .a files in question? Maybe we can figure out what's going on.

from alien-svn.

I think I've found the problem. SVN's configure is producing static libraries by default. I'll try turning that off.

from alien-svn.

Archive::Unzip::Burst was doing the same thing. I realised today I should have mentioned that, glad you've already found it. I'm pleased to offer any guidance on XS/EUMM stuff but I'm otherwise kind of tied up with EUMM stuff as there's an upcoming release deadline.

from alien-svn.