Q for ExtUtils::MakeMaker experts

[kj]

I have a large distribution that contains one small XS (it is
essential for performance, but conceptually rather secondary).

This causes ExtUtils::MakeMaker (or rather ExtUtils::Install) to
install the *whole* distribution under arch, even though 99% of
the installation is 100% architecture-independent!

Granted, there's nothing inherently wrong about this, other that
it is confusing to the casual observer (who is not even aware of
this small XS). And it seems perverse. And it annoys me.

Is there a good way to cajole EU::MM/EU::I into installing only
the architecture-dependent stuff under the arch directory?

I have tried all sort of tricks, but the best I have managed has
come at the expense of a grossly overgrown Makefile.PL, where most
of the additional code is there only to work around what EU::MM is
determined to do. This solves a confusing situation by creating
a new one.

Thanks!

kj

P.S. I'm aware of Module::Builder, but M::B enforces a policy that
requires the module maintainer to specify a license out of a small
set of possible choices, which is out of the question for us.
Besides, even if we could solve the problem above with M::B, we
use EU::MM for all our other packages (about 15 of them in total),
and EU::MM is still the Perl standard, we have decided to give
priority to the EU::MM-based installation option.

 

[Sisyphus]

I have a large distribution that contains one small XS (it is
essential for performance, but conceptually rather secondary).

This causes ExtUtils::MakeMaker (or rather ExtUtils::Install) to
install the *whole* distribution under arch, even though 99% of
the installation is 100% architecture-independent!
..

Is there a good way to cajole EU::MM/EU::I into installing only
the architecture-dependent stuff under the arch directory?

Not sure that I follow this all that well. I'll assume that you've got a
bundle of modules, and you're wanting to install 99% of them into
$Config{sitelib}, but that 99% (along with the other 1%) is going into
$Config{sitearch}.

In the Makefile.PL you can temporarily override those %Config values by
placing at the start of the Makefile.PL something like:

use Config;
BEGIN {
my $obj = tied %Config::Config;
$obj->{sitearch} = $Config::Config{sitelib}
};
use ExtUtils::MakeMaker;
.... etc

So ... I'm thinking you might be able to change the arch directory to what
you want by modifying the pertinent Makefile.PL(s) along those lines ....
but even if that does apply to your situation, I don't know that it can be
made to work (there's the problem of having the values overwritten for 99%
of the modules but not for the other 1%) .... and even if it can be made to
work, that doesn't necessarily mean it's the *best* way to do it.

(Perhaps $Config{installsitearch} needs to be overwritten instead/also ....
perhaps there are other %Config keys whose values need to be overwritten
instead/also.)

The code in the above BEGIN block is pinched from ExtUtils::FakeConfig - so
alternatively you could install that module and use it instead.

I'm no EU::MM expert, btw - and I don't think I needed to point that out

Cheers,
Rob

 

[kj]

One approach might be to isolate the XS functionality in a small module
of its own with its own build and distribution. This module could then
become a prerequisite for the rest of your distribution, which would
then be 100% architecture-independent.

Yep, I think this is what I'll end up doing.

Thanks,


kj