I am gonna kill the Perl ExtUtils::MakeMaker module. I have had it up to here trying to workaround the deprecated uninstall target, for some reason in a major release (5.6.1 I think it was) they flubbed packlist reading and this led to the demise of uninstall. And the Perl community doesn't really seem to care or even recognize the necessity--the absolute necessity I maintain--of an uninstall which reverses the action of install exactly. This is what I hear instead:
"As modules are almost never uninstalled the uninstall option isn't apparently a high priority."
"I've asked one of the authors of CPANPLUS for an uninstall mechanism, but I didn't get the impression I could convince the author of the desirability of it. "
"I've upgraded several packages via cpan.pm and never had to uninstall them before."
How the heck are people supposed to test out my KB app under various configurations (platforms, databases, xslt processors, perl versions, the myriad combinations of perl module versions it could use, it goes on and on) if they're stuck with their first install for life? They could go in and manually remove all installed files and directories but that's just ridiculous, the build process is automated for a reason.
Reversibility is crucial and these people seem blind to the idea.
A problem I've had a couple times now with cygwin make is the fatal "unterminated quoted string" error. I figured it out the first time and then forgot so here I am writing it down for good. In my case, it's caused by the LIB environmental variable set by VS.net to a windows C: style pathname. This is also important: to debug makefile problems the best thing to do is a "make -n" which prints the lines make is trying to execute. I always forget this too, and end up searching unsuccessfully for a make debugger.
Two hours later and I am running NTFS, my laptop is faster than it has ever been, and I magically have an extra 2GB of disk space. This is damn cool. All I did was run "convert C: /FS:NTFS" and on reboot it took care of business. Took about 1 hr for a 20GB drive. Have heard that the 512 byte cluster size inherited from FAT32 is not optimal for NTFS, that it should be using 4K, but who cares? My standard of living just improved.
Here we go down the rabbit hole. In cygwin on my laptop I was messing around trying to get an automated install of all kb dependencies with the CPAN module, and it kept bombing out on libwww-perl, couldn't finish untarring the tarball. So I try to do this manually and sure enough I get "Cannot utime: invalid argument" and tar dies. On my freebsd machine there's no such problem, but I realize the date is about 1970 on the file, close to the UTC epoch. I download the tar sources, comment out the error trap, and that works okay on cygwin. I grab the cygwin source too and look for utime to no avail. Then I start doing tests and narrow down the problem date to about 1980; before that, utimes fail on the file.
After hours and hours it turns out FAT32 cannot create files dated earlier than 12/31/1979. So now I am considering upgrading to NTFS if that is at all possible. My god.