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

Re: merging make_ext and make_ext_cross

Thread Previous | Thread Next
Nicholas Clark
January 10, 2009 12:11
Re: merging make_ext and make_ext_cross
Message ID:
On Fri, Jan 09, 2009 at 08:29:20AM -0500, Andy Dougherty wrote:
> On Fri, 9 Jan 2009, Nicholas Clark wrote:
> > Is there any reason why core should run a single shell script as part of the
> > build process once miniperl has been linked?
> There is no compelling reason.  make_ext mostly reflects the fact that at 
> the time, having just spent several months deeply involved in that massive 
> shell script known as Configure, I was much more comfortable writing shell 
> scripts than perl programs!  (It also reflects that neither DOS/Windows 
> 3.1 nor VMS compatibility was on my mind, and my bias that if you're 


Back in 1995, VMS was the future. And Win32 the future's future.
At least as far as Perl portability went.

> mainly going to just run a few external programs anyway, sometimes a shell 
> script is the right tool, under Unix.)

Yes. It's just that different people have different ideas about where the
trade off is, and most of us these days put the trade up to Perl rather early.
I guess a lot of us are ignorant of the finer parts of shell scripting. Perl
let us become lazy.

Plus things inevitably grow, so what started as the unambiguous right choice
might find later on that it isn't scaling well.

There seems to be one possible "problem" with converting it from shell,
the part of the change

that deals with

        Explicitly use #!/bin/sh to start it up.  This is useful
    for testing make_ext.
        Improve & simplify Nested::Extension::Processing.
        More robust handling of `make clean'.

which added this:

*clean) # If Makefile has been moved to Makefile.old by a make clean
	    # then use Makefile.old for realclean rather than rebuild it
	    if test ! -f $makefile -a -f Makefile.old; then
		makeopts="-f $makefile"
		echo "Note: Using Makefile.old"

If I understand the workings correctly, the purpose of this is that if you run
'make clean', then in order, Makefile causes


3:    make_ext to visit every build extension in ext/ running make clean
3.1:  which deletes all the build time files
3.14: and renames Makefile to Makefile.old


42:   delete all the object files and miniperl

Then if you want to run 'make distclean', the Makefile wants to cause

3:    make_ext to visit every build extension in ext/ running make clean

which would be tricky, as there isn't a Makefile there any more, and you need
miniperl to build one, which has also already been deleted.

So the trick is to save the Makefile as Makefile.old and use that for

This, of course, all works fine if make_ext is a shell script, as it doesn't
rely on anything we built to run make distclean. But if we simply change
make_ext to rely on miniperl, we have a problem if we run make clean;
make distclean, as it has already gone.

Not certain what to do, but it strikes me that as make_ext runs it could
write out the shell* instructions to run distclean into a shell "script" at
top level, and we could change realclean (and distclean) to use that, rather
than recurse into ext/ via make_ext.

Oh, and thanks to Sam for making it rather easy to get blame annotation direct
to this nearly 14 year old change.

(And thanks to Andy for still being around to answer questions. Long may you
not feel like retiring completely)

Nicholas Clark

* For some value of shell, be it /bin/sh, or DCL.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About