Hi Niko, On Sun, Dec 15, 2019 at 02:49:43PM +0200, Niko Tyni wrote: > IMO you're expecting too much from this stuff. > > I don't think the upstream Perl community even knows about these cross > build experiments. I'm not aware of any other distros working in this > area either (though I'm happy to be proved wrong). It's all a pile of > Debian specific hacks abusing upstream features designed for other things.
That's an interesting point of view. Let me try to get more context here. One other relevant distribution is buildroot. I found that buildroot packages libnet-ssleay-perl for instance: https://github.com/maximeh/buildroot/tree/master/package/perl-net-ssleay This seems to use a "perl-package" build class: https://github.com/maximeh/buildroot/blob/master/package/pkg-perl.mk -> We can see that all build tools are passed as commandline @ARGV assignments. Another relevant player would be PtxDist, but they don't seem packaging perl modules. Yocto has a whole meta layer for cpan: https://github.com/meta-cpan/meta-cpan The build class here seems to be called "cpan": https://github.com/openembedded/openembedded-core/blob/master/meta/classes/cpan.bbclass -> I don't quite understand how they do cross compilation, but they seem to be exporting host architecture dependent PERL_INC, PERL_LIB and other things. For OpenWRT there seems to be a package class "perlmod": https://github.com/openwrt/packages/blob/master/lang/perl/perlmod.mk -> Like with buildroot, build tools are passed on the commandline. If we count Debian in, this is four different Linux distributions all trying to cross build (part of) cpan. I think this shows that moving some of the integration upstream is worth a try. The less each and every distribution diverges here, the less work there will be. > Sure, it would be nice if ExtUtils::MakeMaker differentiated between > build dependencies for build and host architectures. But that would mean > proper upstream design for cross builds and all and I don't have an itch > to push that myself. I understand that you don't want to drive this. A the moment, I'm trying to figure out what the ideal solution would be. The question of who drives that solution is secondary to me. > As for a single source of truth: Config.pm is already chosen based on the > (Debian specific) environment variables so I'd say that's still the single > source. I suppose I can bake the host multiarch triplet information into > Config.pm (like I did for debian_abi) if that helps, but it'd still be > Debian specific. Let me disagree here. dh_auto_configure selects the right Config.pm using environment variables. That's using an interface between the builder and debhelper. It's Debian-specific and that's fine, because the packaging is also Debian-specific. As soon as we call into the upstream build system (e.g. Makefile.PL), these variable should cease to be a relevant interface, because this interface should be distribution-agnostic. So imo, choosing the right Config.pm based on the environment is fine and still constitutes a single source of truth. I don't think doing a Debian-specific addition to Config.pm for cross building is a good solution, because it'd require patching at all ends and maintaining those patches in Debian. Either a solution can be shared with others or we should keep it as simple as possible. > I think passing the right pkg-config in as an environment variable like > your patch does is quite adequate. If there are any actual cases where > the build needs the native pkg-config too, I guess that needs to be > handled as a special case. If we assume that our solution cannot be upstreamed, I agree with that. That'd make me sad though. In a number of (non-perl) occasions, I've encountered that one of our other cross distributions had fixed a cross build bug with a patch that wasn't upstreamable (often called "hackfix"). I've tried sending real and upstreamable patches in such cases to permanently get rid of the need to patch. So I think the key here is to propose a useful interface for communicating pkg-config and then agreeing with all other users on that interface in order to be able to upstream the resulting per-module patches. I guess the next step is searching through our lib*-perl build failures for occasions of using pkg-config. Then match those failures with other distributions to encounter prior art and finding a common denominator. I plan on looking into this, but not today. Helmut
