Re: VMS, configure.com and nonxs_ext

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