Glenn Linderman schrieb:
The workaround for now is to include via -M the sub-modules
Image::Info::type for each type of file that you wish to support in your
application.
That's what I said via RT, but my answer wasn't cross-posted to the
mailing list, it seems.
Does your Module::ScanDeps solution simply include them all, Steffan?
Yes.
They aren't very big, so it isn't a very big issue, but a program that
handles only JPEG wouldn't need TIFF, and vice-versa. But the way the
code is written, the dependency isn't obvious (hence the
Module::ScanDeps needs special code, or the build process needs special
code), but I can't imagine any fix to Module::ScanDeps that wouldn't
simply pull in _all_ of the submodules, needed or not...
I've been using the -M sub-modules workaround for some years, including
only those modules my various applications need, based on the types of
files they actually process... which I know, but Module::ScanDeps
wouldn't...
Well, technically, Image::Info loads the Image::Info::* submodules on
demand at runtime. I.e. if you open a JPG, it loads Image::Info::JPG (or
so, I haven't looked at the module name). Now, the Image::Info public
API lets the user *not care* about this loading-behind-the-scenes. If we
don't include all submodules, we wouldn't offer a fully working
Image::Info from the PAR.
Since you're using -M to include extra modules, you'll know about the -X
option to exclude them, too. If you want to fine-tune your packages,
that's cool. But people who are not as experienced with PAR usually
prefer it to work over it producing slightly more streamlined packages.
So yes, Module::ScanDeps now flags the whole Image::Info distribution as
dependencies if Image::Info is used.
Steffen
