in reply to ExtUtils::MakeMaker and dot files

This really does seem like it should be a non-issue. The default MANIFEST.SKIP is usually smart enough, but if you find that you have to add some skips to it, look at ExtUtils::Manifest, where you can read everything you ever wanted to know about writing a MANIFEST and a MANIFEST.SKIP file.

For what its worth, I never use the make manifest command, but do find make distcheck to be useful. The former will just pull in all files in the build path that aren't skipped by either an explicit skip-file, or by the default one. I don't care for that. But the make distcheck command will just spit out a bunch of messages letting me know what files probably should be added to the manifest. In this case, keeping an up-to-date skip file just serves to silence the warnings.


Dave

Replies are listed 'Best First'.
Re^2: ExtUtils::MakeMaker and dot files
by SleepyJay (Beadle) on Jul 18, 2012 at 19:18 UTC

    Ha. I certainly agree: it shouldn't be an issue. But it is. :)

    Maybe I wasn't clear and it's totally my fault. When I said ".AppleDouble" files, I actually meant "shadow files that live inside of .AppleDouble directories". So, if I have a file "Foo.pm", I would likely also have a related file "./.AppleDouble/Foo.pm". Sorry about that.

    My MANIFEST and MANIFEST.SKIP files are properly set up (and do not include .AppleDouble directories). My script is something like: make manifest; make clean; removeAppleDouble; perl Makefile.PL; make; make install On the make step, all of files like .AppleDouble/Foo.pm get put into blib. That's exactly what I'm trying to prevent!

    (I don't always run that set of commands, usually all I need is removeAppleDouble; make install. But the problem is still there.)

    Essentially, what I want is to stop make from looking in certain directories.

    I am no expert on make, and I've been just taking the commands on faith without fully understanding the intricacies, so I may be missing something.

      Then your MANIFEST.SKIP needs to have something like \.AppleDouble/ in it. (Untested.)

      MANIFEST.SKIP understands regular expressions, so any expression that matches the starting part of the path ought to do the trick. Once you've included your regex to exclude .AppleDouble and its children, your make manifest should be fine. This works for .git, _Include, blib, and many other common exclusions.


      Dave

      My script is something like: make manifest; make clean; removeAppleDouble; perl Makefile.PL; make; make install

      :) Well, there's your problem!

       make manifest without a MANIFEST.SKIP gets you into trouble

      $ dmake manifest C:\perl\5.14.1\bin\MSWin32-x86-multi-thread\perl.exe "-MExtUtils::Mani +fest=mkmanifest" -e mkmanifest Added to MANIFEST: .AppleDouble/Foo.pm

      OOOPS

      $ dmake help |grep "make manifest" -A3 make manifest rewrites the MANIFEST file, adding all remaining files found ( +See ExtUtils::Manifest::mkmanifest() for details)

      With an addition to MANIFEST.SKIP all goes as planned

      $ dmake manifest C:\perl\5.14.1\bin\MSWin32-x86-multi-thread\perl.exe "-MExtUtils::Mani +fest=mkmanifest" -e mkmanifest $ dmake skipcheck C:\perl\5.14.1\bin\MSWin32-x86-multi-thread\perl.exe "-MExtUtils::Mani +fest=skipcheck" -e skipcheck Skipping .AppleDouble/Foo.pm Skipping Makefile Skipping MANIFEST.bak Skipping MYMETA.json Skipping MYMETA.yml

        Folks, I already covered this and I don't know how else to say it: my MANIFEST.SKIP file does indeed exist; it skips .AppleDouble folders; and the MANIFEST file itself does not contain .AppleDouble folders or files. THIS IS ALREADY IN EFFECT.

        And yet my make will still grab lib/Project/.AppleDouble/Foo.pm, even though the MANIFEST *only* says lib/Project/Foo.pm.

        For example:

        $ make ... cp lib/Project/Foo.pm blib/lib/Project/Foo.pm cp lib/Project/.AppleDouble/Foo.pm blib/lib/Project/.AppleDouble/Foo.p +m ... $ cat MANIFEST ... lib/Project/Foo.pm ...

        The MANIFEST did not call for the files in the .AppleDouble folder, but they are still copied to blib. This is still a problem.