Bug#762638: metaconfig source control/distribution and Debian's DFSG

[Helmut Grohne]

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".