arsv/perl-cross

Upstream nixpkgs's out-of-tree module cross-building support

shlevy opened this issue · 6 comments

shlevy commented

In shlevy/nixpkgs@7f42025 (not yet merged in master), I made it possible to use perl-cross's miniperl to cross-build modules outside of the perl build itself. It seems like most of the work could be useful as part of perl-cross itself. The full details are at the commit, but essentially this would entail:

Thoughts? Is this something you'd be interested in?

shlevy commented

The cross_perl directories are as far as I know new in this work. Definitely open for a suggestion of a better place to put them.

shlevy commented

An example taking advantage of cross_perl to make things depending on DBI cross-buildable: shlevy/nixpkgs@7a13466

arsv commented

Installing miniperl with the rest of the distribution

This is really unusual, at least for the build environments I'm used to. Generally the idea is to keep host tools out of sysroot. Some things may accidentally work, but it's probably not a good idea to rely on that.

Installing miniperl with a bunch of stub modules is certainly possible, no problem with that as long as it's not done by default. How much sense it makes is another question. CPAN puts no restrictions on module use in Makefile.PL. The trick with cnf/stub/ and miniperl_top works for the limited set of modules bundled with perl, I'm not really sure how well it extends beyond that. And there's another problem, at some point miniperl stops being mini-perl and becomes just perl.

Buildroot does not even bother with miniperl. They require full-featured host perl and run it with a custom Config.pm to build arbitrary perl modules out of tree.
https://git.buildroot.net/buildroot/tree/package/pkg-perl.mk
Not sure how easy it would be to do the same in Nix. You would probably need to build host-perl the same way you build the cross-compiler.

When patching modules in place, be aware of t/porting/customized.dat.
The list is much shorter in recent versions but in 5.24.x it was still pretty long.

shlevy commented

This is really unusual, at least for the build environments I'm used to. Generally the idea is to keep host tools out of sysroot.

Sorry, I translated poorly out of the nix model of things. Basically you'd install miniperl wherever you would install a cross-compiler.

They require full-featured host perl and run it with a custom Config.pm to build arbitrary perl modules out of tree.

Assuming we use the same version etc., is custom Config.pm all that's needed?

arsv commented

Basically you'd install miniperl wherever you would install a cross-compiler.

Then you don't need the whole cross_perl thing. Just pick the required modules from ./lib, from ./cnf/stub, maybe from other locations, install them somewhere and run miniperl -I location like miniperl_top does it.

Assuming we use the same version etc., is custom Config.pm all that's needed?

Nope, but it's a good starting point. Some modules will require patching no matter what's in Config.pm.
Stuff like this: https://git.buildroot.net/buildroot/tree/package/perl-xml-libxml/0001-Makefile-PL.patch. And I think some modules may run build time tests, autotools style. Most should build correctly with the right Config.pm though.

Version match between the host and the target perl is not really necessary as far as I'm aware.

shlevy commented

OK, I think we'll go that approach long-term. Thanks!