On Sun, Dec 14, 2003 at 09:54:30PM -0600, Craig A. Berry wrote: > So the early expansion of macros is probably causing trouble.
Looks like it. Thanks. > "chmod 0755 [.foo.bar]" doesn't mean what you'd think it means. We > are changing the protection on a file with a zero-length name in the > directory [.foo.bar], which on recent VMS systems is a noop and on > older ones is a fatal error. *grabs paper bag to muffle frustrated screams* Shouldn't chmod() just DWIM? *sigh* Its not too bad. ExtUtils::Command::chmod() can be adapted to do the necessary voodoo. > If you want to change default > protection on a directory, you need to manipulate the directory file > itself: "chmod 0755 [.foo]bar.dir". eliminate_macros followed by > fileify should do the trick. I don't recall the dir_target system having to do this. Maybe it just never worked. https://rt.cpan.org/NoAuth/Bug.html?id=4676 > The other problem is with how we are attempting to update the > blibdirs target. The following statement: > > $(NOECHO) $(TOUCH) blibdirs > > will update (and if necessary create) the file blibdirs.;1, where the > version number beginning with the semicolon is optional but the dot > is not. When the build utilities MMK and MMS check the revision date > of C<blibdirs> they will not look for C<blibdirs.> with a dot. In > other words, as far as I know, a bareword target name will always > have a revision date of the time of the build and will never > reference an object in the filesystem. I believe this is what is > causing the repeated and unnecessary builds, and yes, it is still > happening with the current snapshot. There was a workaround for this > same problem in a former incarnation of pm_to_blib. Oh, *that's* what pm_to_blib.ts was for! Maybe I should put that back. https://rt.cpan.org/NoAuth/Bug.html?id=4675 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
