Nicholas Clark wrote:
> On Tue, Mar 03, 2009 at 08:07:04PM -0800, Michael G Schwern wrote:
>> Craig A. Berry wrote:
>>> On Fri, Feb 27, 2009 at 5:14 PM, demerphq <[email protected]> wrote:
>>>> 2009/2/27 Michael G Schwern <[email protected]>:
>>>>> The plan changed in the middle of this argument and I think that wast
>>>>> lost. I
>>>>> no longer plan to do it with make subtests but rather by hacking t/TEST
>>>>> and
>>>>> t/harness. It should work out to no visible change. Rather than
>>>>> untangle the
>
> I like this plan.
>
> I'd been thinking about all this (before reading the rest of the thread) and
> had concluded that
>
> a: I'd changed my mind from "mmm, more change than I feel comfortable with" to
> "a good idea, as it simplifies things"
> b: That the right way to do it (at least for t/harness) is to get TAP::Harness
> to run everything, and know how to change directory.
I ran into a problem with b. Using exec() I can make TAP::Harness chdir
before running the test, but I can't make it chdir back without using
something funky like an end of scope object. So it would be nice if that were
possible, maybe with the simple expedient of allowing exec() to return a
filehandle instead of a program to run.
Meanwhile, I'm going to put the logic to run a core test into its own little
program. This solves three problems. The one above, because now TH can just
exec it. It removes duplication between TEST and harness. And three, it
makes it easier to run a single test from the command line. Rather than
having to duplicate all the stuff that TEST does, you can just run the little
wrapper script.
>> The effective change to the testing system is rather small. Here you can see
>> it without refactorings.
>> git diff 1a129493906affc7fd0e26067910a344e22fb5f2^..HEAD t/TEST t/TestInit.pm
>
> Is there an easy way in the github UI to let me do the above, without needing
> to clone to local disk? Likewise, is there an easy way on the github UI to
> get a diff between two forks? (in this case, your branch, and the mirror of
> blead)
If its there I haven't found it.
>> ext/ExtUtils-MakeMaker/lib into lib is incomplete. I'm not sure how that
>> should best be done. Ideally I'd like make to take care of it so that as
>> ext/ExtUtils-MakeMaker/lib is edited, it will be copied into lib as
>> necessary.
>
> I'm not sure on this. The best I could think of was to go from having 3
> classes
> of "extension" in the core's Makefile - dynamic, static and non-xs, to 4,
> those 3 plus "early". "early" gets built first, before the other 3, and
> might just be ext/ExtUtils-MakeMaker, and it would be "built" with a bonus
> "-Ilib", ie
>
> cd ext/ExtUtils-MakeMaker
> ../../miniperl -I../../lib -Ilib Makefile.PL
> make
> cd ../..
>
>
> (either one early, and a bonus "-Ilib", or 1 for each dir in "early"
> map { "-I../../ext/$_/lib" } @early;
> which wouldn't get out of hand if there aren't that many directories in the
> "early" class)
>
> "early" would essentially be the configure_requires and build_requires for
> any other module in ext.
>
> I'm not sure if that meets your goal of if "ext/ExtUtils-MakeMaker/lib is
> edited, it will be copied into lib as necessary", but I don't think we have
> that right now on anything else in ext/
Aside from ensuring lib/ keeps in sync with ext/ there's another desire.
MakeMaker relies on core modules. Right now things work because it doesn't
rely on anything in ext.. I think. MakeMaker, like most modules, doesn't
spell out its core requirements. But with MakeMaker building itself out of
ext we can rapidly run into a circular dependency problem where MakeMaker
needs something else in ext.
Anything MakeMaker needs has to be cracked up into lib which is counter to the
goal of pulling CPAN distributions back together. Case in point, File::Spec
which is really part of PathTools. It's scattered between lib/ and ext/Cwd.
Very little works without File::Spec.
If instead of having the pumpkings copy PathTools-X.YY/lib/ into lib/ by hand,
or whatever clever script exists to do it, we incorporated it into the build
process so that it copied from ext/PathTools/lib/ then we'd have a generic
system for dealing with this problem not just for MakeMaker but for every dual
life non-xs module that lives in lib.
One way to implement it to have Makefile.SH iterate through the
ext/$non-xs/lib directories and create targets like this:
lib/ExtUtils/MakeMaker.pm: ext/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm
cp ext/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm $@
lib/ExtUtils/MM_Unix.pm: ext/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
cp ext/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix $@
and so on.
--
Ahh email, my old friend. Do you know that revenge is a dish that is best
served cold? And it is very cold on the Internet!
