develooper Front page | perl.perl5.porters | Postings from February 2009

Re: restructuring ext (Re: merging make_ext and make_ext_cross)

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 10, 2009 05:23
Subject:
Re: restructuring ext (Re: merging make_ext and make_ext_cross)
Message ID:
20090210132300.GE81285@plum.flirble.org
On Tue, Feb 10, 2009 at 02:15:24PM +0100, Rafael Garcia-Suarez wrote:
> 2009/2/10 Nicholas Clark <nick@ccl4.org>:

> > With that done, I can change make_ext.pl to fake up an appropriate Makefile.PL
> > in any extension that does not yet have one. At which point it's possible to
> > delete ext/Safe/Makefile.PL (and possibly others), and then we're ready to go
> > on moving dual life modules from lib to ext/...
> >
> > (with the same layout as their CPAN distributions, for the improved sanity of
> > all)
> 
> Since CPAN distributions have Makefile.PL, what's the point of not
> including them in the core then ?

Well,

0: Laziness. I was just planning to re-arrange the current files in git, rather
   than go to CPAN to find the correct Makefile.PL and add it in.
   Nothing would stop the next person updating the module from CPAN to add in
   the correct Makefile.PL

1: The Makefile.PL on CPAN may well specify dependencies that core will meet
   by the time the tests are run, but not at the point when the Makefile.PL is
   run. So we'd get spurious noise about missing dependencies, or have to hack
   the Makefile.PL specially.

2: In theory we could also run a Build.PL

It seemed easer to have the flexibility to be able to build without a
boilerplate Makefile.PL

> > Also, moving things around revealed that we have rather a lot of .gitignore
> > files in and under ext/
> >
> > Some of them have lines that seem to duplicate each other. Given than none of
> > these originate from modules on CPAN, it would seem to me to be cleaner
> > (and less repetitive) to refactor all of them into a top level ext/.gitignore
> > Is this sane?
> 
> Certainly. It might be more practical for some patterns to
> factor them in ext/.gitignore than in a top-level .gitignore.

That was sort of what I was thinking - that it might not be possible, or
clearest, to move everything into the top level .gitignore in the tree. Right
now ext/.gitignore starts

# ignore generated .c files, and other module build traces
*.c

which, I think, is quite appropriate for ext, and quite inappropriate for the
top level :-)

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About