On Wed, Dec 12, 2012 at 11:19:18AM -0600, Craig A. Berry wrote: > 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.
I think that it's been manually updated, and I when I looked at it previously I couldn't work out (for sure) what the inclusiong criteria was, but it seemed to exclude generated files. > >> IMO it cannot continue to work like this. Each perl should include a > >> manifest of such files, which MakeMaker should use. I started out on this about a revision or two back. Config::header_files() returns a list of header files to depend on (which I attempted to list as the list of non-generated files installed on *nix, Win32 and VMS. IIRC that list differs. > >> 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. I hadn't considered this. My plan from Config::header_files() was to merge the generation code in MM_Unix and MM_VMS, and go from there to using Config::header_files() (if present) else defaulting to the historical list. It blocked on lack of VMS access to test this. Whilst I have this now (or did last I checked) I hadn't got back to it. I'd love to see someone else do this, if they felt motivated, but I suspect that it needs to be checked on VMS. There's a header in that old hardcoded list that I'd like to kill. Nicholas Clark
