install into platform specific directory (question)

[plicease]

XS modules get installed in platform specific directory like x86_64-linux-thread-multi

Alien dists are frequently platform specific (although they might not be you could have an Alien dist that provides some javascript for example).

I think Alien::Base dists should be installed in the platform specific directory by default. The cases where you wouldn't want to do this are probably small enough that providing a manual override option to turn this off would probably be sufficient. Detecting for platform specific files (.so, .a files) would also be a nice to have.

I think migrating should not be a big problem, as the arch directory seems to come before the non arch directories:

twin% perl -E 'say $_ for @INC'
/home/foo/.perlbrew/libs/perl-5.20.2t@dev/lib/perl5/x86_64-linux-thread-multi
/home/foo/.perlbrew/libs/perl-5.20.2t@dev/lib/perl5
/home/foo/perl5/perlbrew/perls/perl-5.20.2t/lib/site_perl/5.20.2/x86_64-linux-thread-multi
/home/foo/perl5/perlbrew/perls/perl-5.20.2t/lib/site_perl/5.20.2
/home/foo/perl5/perlbrew/perls/perl-5.20.2t/lib/5.20.2/x86_64-linux-thread-multi
/home/foo/perl5/perlbrew/perls/perl-5.20.2t/lib/5.20.2

Though going back once you have converted is tricky (I had this problem with Archive::Libarchive::FFI, which lost its .so file at some point).

There does not appear to be a public interface to tell Module::Build to install into a arch directory, so I am also not exactly sure how we do this.

If there is agreement I think this should be marked as a bug.

[jberger]

This was requested before, I'm not quite sure what problem this solves?

Alien is by definition meant to either (a) build the library locally or (b) use the system library. The point is moot for (b) and for (a) you can argue that the built library is just module data.

[plicease]

The non-arch directory can be shared in a non homogeneous network environment, unless you have modules that break this model. This seems to be the intent of an arch specific directory. You can argue that the library is data, but in most cases it is also arch specific binary code, so I don't see this as a useful argument.

[jberger]

But of course there are even exceptions to that, for example, if it is a Mach binary and the path to the installation directory is different on the two machines, you need to change the binary's baked-in path.

[plicease]

The only example I can think of where Mach is used is on OS X where the arch name is the same.

[plicease]

I believe this is addressed in 0.019. If there is demand for it we can make alien_arch the default, but at the moment there is not the support in the AB team for that.