Comment: "excessive magic" :) (Score 1) on 2010.09.06 23:06
Attached to: Should Module::Install move to explicit plugin declaration?
Yes, agreed...
And a command-line option that lists the plugins for installing via cpanm would be great, too!
Yes, agreed...
And a command-line option that lists the plugins for installing via cpanm would be great, too!
That would do it.
Here's my bet as to why: The 5.12.0 versions run a perl script to do their relocation - when the script fails for some reason, it rolls back - and since it is a script, the only way to tell which file caused the problem is by reading the logs that normally do not get created, but can be asked for. This is something that was improved in the current betas, (we now run a DLL instead of a Perl script, so we can get back more information - running a script only gives us a "successful or not, and if not, log the output of the script" ) but still needs further improvement.
I've wished I had that sort of module in the past, often when debugging testing modules. Unfortunately, I'm not to the point of being able to pull out the magic B wand and make it do what I want to do yet.
When you DO make it into a module, make the regexp {/Test/(*.)\.pm\z}, OK? That way it covers any testing module, not just Test::More.
Maybe that's why there is no SaltLakeCity.pm ?
(and no, I live too far away from SLC to start one [80 miles], and even if I wasn't, I'm one of the 60% [needs verification, but I think that's approximately the right number] of people there that have chosen to not allow themselves to drink beer!)
Windows Installer XML was sorting by the ID I gave the file. Previously, that was a GUID - with results you can imagine. Now, I put the extension, and then a CRC32, into that ID, so it sorts by the extension now.
#5: in Strawberry's case, we provide the C/C++ compiler - so it's really not external, but it is provided for those things that need it. For most non-Windows operating systems, I do have to admit, Perl assumes that a C/C++ compiler is accessible for a lot of things.
And "Strawberry Professional" will have a lot more things prebuilt.
We "do" have a way to ship binaries, at least for one module at a time - it's called a
I don't necessarily use consecutive numbers, instead, I use three-digit numbers, with the first digit indicating a "category".
This is from one distribution of mine.
001_compile.t
100_machine.t
102_misc.t
103_wix_component.t
104_wix_fragment.t
111_environment.t
112_files_entry.t
113_files_component.t
114_files_directoryref.t
115_startmenu.t
116_registry.t
117_directorytree.t
118_icons.t
119_createfolder.t
120_feature.t
121_files.t
122_removefolder.t
500_new.t
800_perlcritic.t
801_pod.t
802_pod_coverage.t
803_minimumversion.t
804_manifest.t
805_meta.t
806_portability.t
807_version.t
899_prereq.t
901_perl_589.t
902_perl_5100.t
903_perl_5101.t
904_portable.t
In this case, the 0xx tests are for compilation only, the 1xx tests do small portions of the distribution, the 5xx is an "overall" test, 8xx are author tests, and 9xx are long-running (we're talking hours) release tests that are guarded with an environment variable.
To each his own, however.