On Mon, Sep 07, 2009 at 08:55:29PM +0100, Nicholas Clark wrote:
> This might be rather a big favour request.
This might be easier than I first thought
> Would it be possible to augment the configure.com code that finds extensions
> to correctly partition "nonxs_extensions" from "known_extensions"?
> (being the rather bonkers way that Configure partitions XS and non-XS
> extensions)
>
> To properly split out dual life modules into ext, I think it's going to be
> necessary to add a Makefile.SH/Makefile/makefile.mk/descrip_mms.template
> rule to have mkppport run after the nonxs_ext are built, but in turn, it needs
> to run before dynamic_ext are built, hence the need for a split.
>
> I'm not sure how easy this is, because right now Configure does it this way:
> using file globbing in ext/, whereas configure.com does it by text processing
> MANIFEST:
> If it were possible to make the above into a function, then partitioning
> nonxs from XS would seem to be as simple as
>
> Feed the function the equivalent of `grep \.xs MANIFEST` to find the XS
> extensions
I think that "every" XS extension has exactly one file named *.xs in it. Try
running
perl -nlwe 'print $1 if m!^(ext/[^\/]+/\S+\.xs\b)!' MANIFEST
exclude from the output ext/DynaLoader (which is already a special case in
configure.com) and lines matching 'fallback/constants.xs' and one has
the list of all XS extensions. I hope that this algorithm is easy to
encode in DCL.
> Feed the function MANIFEST to find all extensions
>
> Iterate over the list of all extensions - everything that isn't an XS
> extension, you put into nonxs_extensions
At which point the existing code in configure.com can be changed around
$ may_already_have_extension:
to exclude any "new" extensions that are already in the list of XS extension
generated above, and tweak it to replace
$ known_extensions = known_extensions + " ''extspec'"
with
$ nonxs_extensions = nonxs_extensions + " ''extspec'"
Nicholas Clark
