Thanks for the suggestion karlgoethebier, though I do have a way to make Date::Calc work as it should anyway. I was just really confused by how something as seemingly inconsequential as listing all the use statements on one line vs. separate lines could make the .exe either fail or work respectively with no other difference... very odd to me, since it didn't seem like it should ever matter.
Just another Perl hooker - But the purist monks keep telling me I should do it for love, not money.
| [reply]
[d/l] |
... listing all the use statements on one line vs. separate lines could make the .exe either fail or work respectively with no other difference... very odd to me, since it didn't seem like it should ever matter.
Perl is very hard to parse statically, maybe even impossible (although PPI does a decent job, considering). So quite a few tools resort to doing a simple line-by-line/regex parse of Perl source files to find out simple things, hoping that the authors of the code stuck to some common styles of writing Perl. For example:
- The PAUSE indexer parses package ...; lines (and there is a simple trick to hide packages from the indexer),
- some tools like ExtUtils::MakeMaker parse the our $VERSION = ...; line in modules (see the doc of VERSION_FROM and ExtUtils::MM_Unix->parse_version, Update 2: and see this node for even more modules that do a static parse on module versions), or
- pp uses Module::ScanDeps which uses a "static-scanning heuristic" (I take that to mean regular expressions) to find the dependencies - and indeed swl has analysed the issue there a bit further.
Updated: Added a few minor specifics.
| [reply]
[d/l]
[select] |
