Dear Perl maintainers, On Sat, Oct 04, 2014 at 05:50:51PM +0100, Dominic Hargreaves wrote: > I'm including Helmut, the submitter to the Debian bug report, as a > CC, in case he can help provide additional context that I'm missing.
Yes, I do have additional context. > I don't have the exact details, but Helmut suggests that this wasn't > the case for him, as the changes would have had to be made in several > places. In general I think a healthy free software project should aim to > minimise cases where a casual hacker would be discouraged from doing > things the same way a seasoned developer would. I have to admit that I am no longer 100% sure that I do indeed want to modify metaconfig units rather than just patching Configure, but given my experience with autoconf that initially seemed like the logical way to do it. I can give background on what I would like to see changed about Perl's Configure, but it'll be a longer read and it may not help solving the question as to whether metaconfig is to be considered part of the Perl source (from a Debian pov). The one extra bit I can give here is that reading metaconfig units helps with understanding Configure. I do not understand much of the other details involved, so the rest of this mail concentrates on my particular use case: Cross building Perl is hard. When Perl is cross built, it most often is a retrospective. In other words, you built it natively and collected the Configure results to be able to reproduce them as part of a real cross build. I am aware of two cross building efforts for Perl. One is Neil William's perl-cross-debian[1] and the other is OpenWRT, which apparently provides a microperl. Neil William's effort basically gathers the Configure results an treats them as source. Since these results change with Perl releases, perl-cross-debian is hard to keep up to date and it does not work with any non-ARM architectures at the moment. Ideally, Perl would cross just like any other language, but we are very very far from that. So one way to make crossing Perl more feasible is to reduce the effort of maintaining the Configure results and one way to reduce that effort is to reduce the number of checks that need to execute host[2] arch code. Indeed, there is very much low hanging fruit here. Checks such as the *size checks or d_open3 and o_nonblock can be turned into compile-only checks (i.e. without running host[2] arch code). Since the *size checks are very much repetitive, it seemed natural to me that modifying metaconfig is the way to go. Once a good portion of these checks is turned into compile-only checks, the remaining checks may become maintainable enabling reasonable cross compilation. The documented method of cross compiling Perl is a bad joke. It presumes that one actually has a host[2] architecture machine, but for a long time arm64 and ppc64el hardware was unavailable and it is still hard to come by today. It also presumes that one has a ssh server on the host[2] architecture machine, but building openssh requires Perl. So in my view, Perl currently makes cross compilation unnecessarily hard and the place to fix that is Configure. Helmut [1] https://github.com/codehelp/perl-cross-debian [2] I am using GNU terminology here, because it is most widely accepted. Perl's documentation refers to this as "target". -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org