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

Re: merging make_ext and make_ext_cross

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
January 30, 2009 15:39
Subject:
Re: merging make_ext and make_ext_cross
Message ID:
20090130233848.GS95022@plum.flirble.org
On Fri, Jan 30, 2009 at 09:55:45AM -0600, Craig A. Berry wrote:
> On Thu, Jan 29, 2009 at 4:01 PM, Nicholas Clark <nick@ccl4.org> wrote:
> > On Fri, Jan 09, 2009 at 09:08:36AM -0600, Craig A. Berry wrote:
> >
> >> FWIW, on VMS we currently generate a make_ext.com on the fly within
> >> configure.com.  It's about 70 lines of DCL that basically runs
> >> miniperl and the make utility a bunch of times.  I don't see anything
> >> offhand that would prevent its replacement with a pure Perl
> >> equivalent.  No doubt we would have to add a wrinkle or two, such as
> >> grabbing extensions under vms/ext/ as well as ext/.

Ah yes. I've found it. In this:

$    If redesc Then -
       miniperl "-I[''up'.lib]" Makefile.PL "INST_LIB=[''up'.lib]" "INST_ARCHLIB=[''up'.lib]"  "PERL_CORE=1"
$    makeutil 'targ'

I infer that 'targ' expresses an interpolation of the variable targ, set
earlier by

$    targ = F$Edit(p3,"Lowercase")

But what does the doubled single quote in ''up' mean? Read from the
environment (or the next level of environment outwards)? up seems to be set by
the snippet of earlier perl:

     ($ENV{'up'} = ('-') x ($extdir =~ tr/././));

(dot being the VMS directory separator, for anyone following along at home)

I see from descrip_mms.template that the VMS "makefile" supports both
clean and realclean targets.

How does VMS cope if you type the equivalent of

make clean
make realclean

?

The Unix Makefile doesn't *quite*, because it will delete ./miniperl in
make clean, but some extensions want to use ../../../ etc /../miniperl
in their Makefiles for whatever reason. But as far as I can figure out from
descrip_mms.template it doesn't actually delete miniperl ever. Certainly, it's
using it to run commands in the realclean target.

(I ask, because I added a hack to build_ext.pl to make it work no worse than
the shell version when the user types the above two make commands in order.
I'm not sure if this was a good idea. It might be easer to say "it breaks"
and make it a documented misfeature.)

> > I think that the better solution to this would be to move them from vms/ext to
> > ext/ as Win32, which started with change 29483 and was completed by change
> > 30379. All it *should* take is an analogous patch to Configure to
> >
> > ==== //depot/perl/Configure#636 (xtext) ====
> >
> > @@ -21090,6 +21090,11 @@
> >                         esac
> >                esac
> >                ;;
> > +       Win32)
> > +               case "$osname" in
> > +               cygwin) avail_ext="$avail_ext $xxx" ;;
> > +               esac
> > +               ;;
> >        XS/APItest|xs/apitest)
> >                # This is just for testing.  Skip it unless we have dynamic loading.
> >
> >
> >
> > plus similar logic at the top of win32/FindExt.pm.
> 
> I know folks were keen on this when it was done for Win32 but I never
> understood why.  It doesn't make a lot of sense to me to put
> platform-specific code in a common place where all platforms but one
> have to go out of their way to avoid tripping over it and their build
> capability is broken until they get around to explicitly avoiding it.
> But I'm in dense mode today so maybe there's some sense in it I can't
> see.

It's all a compromise in where the complexity is.

I suspect that it made it a lot easier to build for cygwin, as it *can* use
the Win32 extensions, but uses Configure to find them, so its logic was
simpler. It actually also made the win32 Makefiles simpler, although no-one
spotted the last 5 lines in each that could go until two days ago - the
conditional references to ext, meaning win32/ext

There's already logic in Configure and (I see in) configure.com to skip
extensions based on various criteria, such as missing libraries, so it's very
little extra to add similar to skip them if the "library" Win32 isn't there.

Also, quite often, it confuses me when I'm trying to look around the Perl
source to find every instance of something, and I forget that some C and
XS files are in other directories. For some reason I sort of expect that
only things relating to getting the build bootstrapped are in other
directories, rather than all things relating to that platform. But this is
probably just me. And the more I type, the more subjective it seems to be.

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