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

Re: merging make_ext and make_ext_cross

Thread Previous | Thread Next
From:
demerphq
Date:
February 1, 2009 09:27
Subject:
Re: merging make_ext and make_ext_cross
Message ID:
9b18b3110902010927v1a6969c7g2a72c89c61b731d2@mail.gmail.com
2009/1/31 Nicholas Clark <nick@ccl4.org>:
> On Fri, Jan 30, 2009 at 07:47:49PM -0600, Craig A. Berry wrote:
>
>> 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.
>
> I don't think that making the description file smarter will be needed.
> Right now, the Windows equivalent, win32/buildext.pl, does the looping,
> and I'm working with Max Maischein to converge it with make_ext.pl
> That will mean adding the looping (as an option) to make_ext.pl, so at
> that point there may not be that much left to do for VMS.
>
>
> My plan is
>
> 1: Converge make_ext.pl and win32/buildext.pl
> 2: Merge the two as make_ext.pl, and swap the win32 Makefiles to use it
> 3: Figure out what is needed to add VMS into make_ext.pl
>
> Once everything is using make_ext.pl
>
> 4: Figure out what changes would be needed in what configuration systems to
>   make them cope with using '-' in directory names -
>   ie ext/Data/Dumper becomes ext/Data-Dumper on disc.
>   (I think that the names in config.sh have to stay as "Data/Dumper" etc)
> 5: Rename the directories in ext/ to that format, so that ext/ is flat, with
>   all extensions at the top level
> 6: Simplify all the ext scanning code - no need to recurse directories, no
>   need to limit the depth to 10 to avoid infinite symlink loops, no need for
>   special cases for ext/threads/shared and ext/Hash/Util
>
> At this point there is a one to one mapping between extensions and directories
> in ext. Every directory there is an extension. So
>
> 7: Add logic to make_ext.pl to write a Makefile.PL automatically for any
>   directory in ext/ that doesn't have one. (and clean it up at the end)
> 8: Start moving dual life modules from lib/ to ext/
>
> Which, I think, long term, will simplify a lot of maintenance issues.

Just a heads up:

Please please dont break the logic of allowing the exts that will be
built be specified on the command line for build_ext.pl

In particular have a look at the nmake based win32 Makefile at the
test-reonly and reonly targets, which both end up calling
Extensions_reonly as the following code/blame shows:

a24cc0c0
	1068	Extensions_reonly: buildext.pl $(PERLDEP) $(CONFIGPM)
a5ca303d
	1069		$(XCOPY) ..\*.h $(COREDIR)\*.*
1a76ca1a
	1070		$(MINIPERL) -I..\lib buildext.pl "MAKE=$(MAKE)" --dir=$(EXTDIR)
--dynamic +re

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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