Re^2: Very Odd Issue When Using pp to Create an .exe File Including Date::Calc

in reply to Re: Very Odd Issue When Using pp to Create an .exe File Including Date::Calc
in thread Very Odd Issue When Using pp to Create an .exe File Including Date::Calc

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.

Comment on Re^2: Very Odd Issue When Using pp to Create an .exe File Including Date::Calc Download Code

Replies are listed 'Best First'.
Re^3: Very Odd Issue When Using pp to Create an .exe File Including Date::Calc by haukex (Archbishop) on Jun 28, 2017 at 13:18 UTC
... 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]

Replies are listed 'Best First'.

Re^3: Very Odd Issue When Using pp to Create an .exe File Including Date::Calc
by haukex (Archbishop) on Jun 28, 2017 at 13:18 UTC

... 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]

In Section Seekers of Perl Wisdom