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

Re: merging make_ext and make_ext_cross

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
January 30, 2009 17:48
Subject:
Re: merging make_ext and make_ext_cross
Message ID:
c9ab31fc0901301747p35029f44u70a0796585651e5a@mail.gmail.com
On Fri, Jan 30, 2009 at 5:38 PM, Nicholas Clark <nick@ccl4.org> wrote:
> 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")

Correct.

> But what does the doubled single quote in ''up' mean? Read from the
> environment (or the next level of environment outwards)?

DCL symbol interpolation.  Inside of double quotes, you have to double
the leading single quote in order to indicate it's a symbol.

$ foo = "bar"
$ show symbol foo
  FOO = "bar"
$ write sys$output foo
bar
$ write sys$output "The symbol foo contains >''foo'<"
The symbol foo contains >bar<
$ write sys$output "With no doubled leading single quote we just have 'foo'"
With no doubled leading single quote we just have 'foo'

And p3 is parameter 3, the moral equivalent of $ARGV[2].

> 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)

Exactly.  A boiled down demonstration:

$ Define/User_mode Perl_Env_Tables CLISYM_LOCAL
$ perl -e "($ENV{'up'} = ('-') x ('[.ext.List.Util]' =~ tr/././));"
$ show symbol up
  UP = "---"
$ set default [.ext.List.Util]
$ dir ['up']miniperl.exe

Directory D0:[craig.perl]

MINIPERL.EXE;1

Total of 1 file.

> 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.

Right.  miniperl is left untouched by the clean target.  It's used
quite bit in realclean, as you note, and then finally deleted towards
the end of realclean by the line that looks like:

        - If F$Search("[...]*$(E)").nes."" Then Delete/NoConfirm/Log
[...]*$(E);*

which deletes miniperl.exe, perl.exe, the perlshr.exe shareable image
(aka dynamic library) and any other .exe files you've accidentally or
intentionally put in your Perl build directory.  Here's what it will
delete in my current dirty build directory:

$ dir *.exe

Directory D0:[craig.perl]

DBGMINIPERL.EXE;1   DBGPERL.EXE;1       DBGPERLSHR.EXE;1
GENERATE_UUDMAP.EXE;1
MINIPERL.EXE;1      NDBGPERL.EXE;2      NDBGPERL.EXE;1

Total of 7 files.


>>  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

>
> 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.

Thanks.  There's something to be said for just doing what everyone
else is doing without thinking too hard about why.

On that note, I've had a quick look at porting make_ext.pl to VMS.  It
wouldn't be that difficult and I'm happy to add the DCL bits if you'd
rather not mess with it.  The hard part is calling it from the
description file (the Makefile equivalent).  Currently the description
file knows nothing about what extensions we are going to build and
depends on make_ext.com to root through config.sh and build what was
selected during configuration.  It only invokes make_ext.com once.  If
I'm reading what make_ext.pl does correctly, we'll have to make the
description file quite a bit smarter so it invokes make_ext.pl once
for each extension that we've configured for.

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