distclean misnamed?
For reference, this discussion started when Jos was looking for a MakeMaker target which deletes everything not in the MANIFEST. Naturally he tried distclean expecting that to DWIM only to find out it doesn't. It does a realclean and distcheck just telling you what's wrong. Initially I agreed with him, and was horrified to find MB had parroted MakeMaker's behavior. However... On Mon, Apr 04, 2005 at 09:26:20AM -0700, Michael G Schwern wrote: However, it seems to be actually only *telling* me what is wrong, without actually removing the wrong files: Reading the documentation, that seems to be the intention as well :( Alas. ARGH! Module::Build parroted MakeMaker's behavior! I take that back. Having distclean deleting files would be a Very Bad Thing. Consider the case where you've just added a few new source files to the dist but haven't added it to the manifest. You (or perhaps some build tool) runs make distclean and poof! new files gone. One could have distclean move the files to some unclean/ directory instead of deleting them, or confirm before deleting, but really the point of distclean is to make sure that realclean does in fact clean out the distribution back to a pristine state. To that end, maybe distclean is misnamed.
Re: distclean misnamed?
Michael G Schwern wrote in perl.makemaker : I take that back. Having distclean deleting files would be a Very Bad Thing. Consider the case where you've just added a few new source files to the dist but haven't added it to the manifest. You (or perhaps some build tool) runs make distclean and poof! new files gone. Not mentioning .svn and CVS dirs and everything that is usually in MANIFEST.SKIP.
Re: [Module::Build] distclean misnamed?
On Apr 4, 2005, at 11:34 AM, Michael G Schwern wrote: For reference, this discussion started when Jos was looking for a MakeMaker target which deletes everything not in the MANIFEST. I would never ever ever ever ever ever ever ever want that. One could have distclean move the files to some unclean/ directory instead of deleting them, or confirm before deleting, but really the point of distclean is to make sure that realclean does in fact clean out the distribution back to a pristine state. I guess so. I was never really sure what it was for, I simply accepted a patch that added it along with some other MM actions I never use. I figured the worst that could happen is that a lot of other people won't use them either. I certainly never assumed it was supposed to clean out your distribution for you, though. This brings to mind the people who try to clean out their brains with power drills, or their intestines with long bits of cloth - likely does more damage than good. To that end, maybe distclean is misnamed. I guess it depends on how you read it. If you read it as clean the dist or make the dist clean, then yeah. But there's already a clean and realclean action for doing that. I'm not sure I can offer an alternate reading that makes any more sense though, so yeah, I guess it's misnamed. Personally, I just have my upload tools do an ExtUtils::Manifest::filecheck() before uploading. -Ken
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01
On Wed, Mar 30, 2005 at 09:42:58AM -0500, [EMAIL PROTECTED] wrote: Would this be less confusing? ExtUtils::CBuilder couldn't find a compiler to test XS builds That would be better. If not too long the line: ExtUtils::CBuilder was not found or it could not find a compiler might be more accurate. By the way is the plan to introduce the new ExtUtils::MakeMaker and the ExtUtils::CBuilder into bleedperl? MakeMaker, yes, but I'll wait until things settle down a bit and its been knocked around some on CPAN. The fact that I've gotten a grand total of one bug report about the busted PL_FILES despite there being some 100+ distributions that use it tells me that 6.26 isn't being used much yet. As for CBuilder? Dunno. Not as part of MakeMaker, but maybe when Module::Build goes in. Would a warning about a missing prereq for the separate CPAN dist of MakeMaker be helpful? I might hack up something in the Makefile.PL that mentions it, but for the moment since its not actually testing anything I'm not worrying about it. The xs.t test is really to see how badly ExtUtils::CBuilder vomits in practice. Now that's unexpected. VMS works but Solaris didn't. Silly case sensitive file system: setup() wrote output files to a directory called PL_FILES-Module then the test came along and attempted to chdir to PL_Files-Module. That scheme worked on VMS and Windows, but not on Solaris (unlikely to work on any Unix). OS X is one, such as my laptop. :) Here is one way to address the problem: Thanks, excellent catch. 6.27 will be coming shortly.
[ANNOUNCE] ExtUtils::MakeMaker 6.27
http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.27.tar.gz or http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk or a CPAN near you Kwikie release to fix a bug in PL_FILES introduced in 6.26. I also made MakeMaker friendly to darcs users (since I'm one now :). 6.27 Mon Apr 4 16:36:14 PDT 2005 * Added _darcs to the list of revision control administrative directories skipped both in libscan and in MANIFEST.SKIP. 6.26_01 Mon Mar 28 21:34:39 PST 2005 * PL_FILES was broken in the last release. The .PL files were not being passed the file they were to generate. * How PL_FILES runs the programs and what it does with the value is now documented. * The default behavior of PL_FILES is now documented.
Re: mm_vms.pm question.
At 9:15 PM -0500 4/4/05, John E. Malmberg wrote: In MM_VMS.PM, there is a comment that unixify will sometimes return a string with an off-by-one trailing null. And what does that mean? More than one null terminator? Perl strings are roughly equivalent to dynamic string descriptors on VMS. The length is stored internally so you shouldn't see the null byte from Perl. It looks like there was a bad length calculation at some point or other problem that caused the length to include the null. This workaround apparently came into the core with the following patch, though may have been in an independent release of MM before that: http://public.activestate.com/cgi-bin/perlbrowse?patch=19099 Do you have a reproducer for that problem? No, but the following bug fix from just about a year ago may be related: http://public.activestate.com/cgi-bin/perlbrowse?patch=22544 http://www.nntp.perl.org/group/perl.vmsperl/12349 -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
