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. > >>> miscommunication in email its simpler and faster for me to just do it and > >>> let > >>> the code speak for itself. > >> That sounds great! > > > > Yes, indeed. Even if the hacks are wicked they'll be corralled into > > one or two places where we can keep an eye on them. > > It is done. Or at least, it is demonstratable. > http://github.com/schwern/perl/tree/ExtUtils-MakeMaker > > 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) > In some cases I moved files out of t/ and back into ext/ when doing so would > restore the integrity of a CPAN distribution and eliminate a PERL_CORE hack. > t/Module_Pluggable for example. I realize some of the moves were made because > of VMS depth limits. I think now that ext has been flattened this should be > ok. If not, a better solution might be for TEST to create a VMS virtual root > for each ext/Module and chdir into that. IIRC Craig thought that we'd now be just inside the limit, so it should all work. > I also made the path to perl and the lib directories absolute so tests can > chdir safely and added "." into @INC so it's more like how perl really runs. > > One debatable bit is t/TEST's use of File::Spec->rel2abs. TEST was already > using File::Spec but now its also using Cwd. Fortunately, Cwd can work as a > Perl module. Also, if things go really bad, you can run TEST using an already > installed Perl. Even a rather old one should work. > > t/harness still needs to be dealt with. And the system for copying > 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/ Nicholas Clark
