On Wed, Dec 12, 2012 at 9:51 AM, Dave Mitchell <da...@iabyn.com> wrote: > On Mon, Dec 10, 2012 at 05:14:34PM +0100, demerphq wrote: >> On 10 December 2012 14:59, Leon Timmermans <faw...@gmail.com> wrote: >> > On Mon, Dec 10, 2012 at 2:30 AM, demerphq <demer...@gmail.com> wrote: >> >> Ah, I think I found it. Apparently MakeMaker.pm has a hardcoded list >> >> of headers. >> >> >> >> The list is incomplete, it omits headers I would expect it to contain >> >> such as utf8.h and regcharclass.h. >> >> >> >> cheers >> >> Yves >> > >> > Worse yet, that makes it rather hard to deprecate headers. I have a >> > branch where two headers are essentially empty but can't be removed >> > because it breaks MakeMaker. >> >> IMO it cannot continue to work like this. Each perl should include a >> manifest of such files, which MakeMaker should use. >> >> We cant be blocked in changing the headers included with Perl because >> of a hard coded list in old MakeMaker's. That way lies insanity. > > Not that I know much about MakeMaker or why it needs a list of perl > headers, but could it, for installed perls, use the list of *.h files > under x86_64-linux-thread-multi/CORE or similar, and when in the build > dir, use ../../*.h?
Makes sense to me, but for some reason has been considered unreliable, such as <http://perl5.git.perl.org/perl.git/blob/HEAD:/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm#l1664> which looks like: 1663 $self->{PERL_ARCHLIB} ||= $Config{archlibexp}; 1664 $self->{PERL_INC} = $self->catdir("$self->{PERL_ARCHLIB}","CORE"); # wild guess for now When or why that was considered a wild guess and at which Perl version it became reliable on all platforms (assuming it has) would probably need to be sorted out in order to move forward. After that, rewriting perldepend() to simply collect all the aitches from $self->{PERL_INC} doesn't seem too difficult.
