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:
Rafael Garcia-Suarez
Date:
February 10, 2009 05:15
Subject:
Re: restructuring ext (Re: merging make_ext and make_ext_cross)
Message ID:
b77c1dce0902100515r6cebc429lcfa304d7aca18716@mail.gmail.com
2009/2/10 Nicholas Clark <nick@ccl4.org>:
> To do this, ext/Safe has become a proper extension (with, for now, a
> Makefile.PL), and Safe.pm has moved there from inside ext/Opcode. However, this
> means that it's now a new, listed, nonxs_ext
>
> I had assumed that all this re-arranging was valid for maint-5.10 too, as
> the names of extensions in config.sh (and by implication Config.pm) has
> NOT changed - it's merely an implementation detail of the build process.
>
> I'm not sure that what comes next (moving things from lib/ to ext/) is good
> to go until after 5.10.1 escapes to CPAN, as when it happens, lots more
> extensions appear in nonxs_ext, and people might be foolish enough to
> deconfigure them. Then again, anyone running Configure with a custom
> command line to force a specific set of nonxs extensions is acting like they
> know what they are doing...
>
>
> Anyway, for now, we're (also) back to needing a tweak to configure.com.
> Right now it scans MANIFEST for m!(?:vms/)ext/.*/Makfile\.PL!
> which means that it won't consider any new directory in ext/ without a
> Makefile.PL as an extension. How complex is it to change it to treat
> all directories in ext (and vms/ext) as extension directories?
>
> 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 ?

> I'm not sure whether git mv IO_Compress_Base IO-Compress-Base and
> git mv IO_Compress_Zlib IO-Compress-Zlib is a good idea, as this *will*
> change their name in nonxs_ext
> Also, with Module::Pluggable now one level less deep in the tree, will its
> tests fit inside it without busting the VMS directory level limit? Or are
> they already at 8 in their location in t/Module_Pluggable?
>
>
> 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.

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