Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: ExtUtils::MakeMaker and dot files

by Anonymous Monk
on Jul 21, 2012 at 00:47 UTC ( #982934=note: print w/replies, xml ) Need Help??

in reply to ExtUtils::MakeMaker and dot files

For those not satisfied with make dist use ExtUtils::MY#libscan

sub MY::libscan { warn "@_\n"; my( $mm, $file ) = @_; return if $file =~ /\.AppleDouble/; return $file; } WriteMakefile( ...

Replies are listed 'Best First'.
Re^2: ExtUtils::MakeMaker and dot files
by SleepyJay (Beadle) on Sep 06, 2012 at 15:34 UTC

    HUZZAH! You have done it!

    I had to add another line to skip, but other than that, this was perfect. Thanks! Gold star for you.

    We really did try to read the documentation (and even the code), but we hadn't yet figured it out. I knew the Perl Monks would get it eventually. :)

    Just to round out the conversation, the SSH client I was trying to use instead of AFP couldn't refresh in the remote to local direction (not even manually) and was causing other issues. So we went back to AFP. But this time, I know the exact reason this was a problem. Whenever I would run make, my IDE would scan for changes, write the .AppleDouble resource fork, and sometimes the make would grab that .AppleDouble. That's where it was causing problems.


    BTW, it's perhaps not much of an excuse, but I just searched for libscan in the perldoc for ExtUtils::MakeMaker and found only one hit under PMLIBDIRS. I don't think this was very obvious of a solution. (Thanks again, this is huge.).

      I thought this was closed, but it turned out to only be a small part of the problem. I think we have fixed it completely.

      If anyone cares, here it is...

      When I navigate around the AFP connected folders in Finder, it writes .AppleDouble folders. But, when I am running make, it's in terminal window, so technically if I remove the metadata, make shouldn't find any .AppleDouble files and it should work as planned.

      However, this is where the editor I use, Komodo, comes it. There is some background process (we've seen it running) of Komodo's that essentially scans all of the documents in your source folders. This includes the Perl make folder--blib. This process tickles AFP for the blib folder, so a .AppleDouble folder (and some files) are written there. If there is a blib/arch directory and it isn't "empty" (it may contain some files that are ignored), then Perl will install to that alternate location and screw everything up. So, Komodo's scans are allowing that folder to not be empty, and thus Komodo is indirectly causing this problem.

      The current fix is to add a line way down in the bowels of Perl that ignores .AppleDouble directories when testing for an "empty" blib/arch folder. That is, of course, a crappy fix because we have to install it separately for each version and machine for which we want to use. (There might be a way to override the function without changing the source.)

      The quick summary is thus: We still need to clean metadata each time before the make. Also, we still need to override the libscan function to avoid these files during the creation of the Makefile. And, we need a stupid one line fix to ignore .AppleDoubles way down deep in Perl's source code.

      BTW, I was working around this by running make clean and perl Makefile.PL before make and make install. That was working nearly flawlessly because the check to see if blib/arch is "empty" doesn't run if blib is missing--which of course it will be after make clean is run. But of course by remaking my entire Perl source each time, I was totally invalidating the purpose of make (build only what has changed).

        ditching apple not an option? :)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://982934]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2018-05-24 14:57 GMT
Find Nodes?
    Voting Booth?