[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GT] users without Date::Manip need this change
Well spotted, use does look for modules during compilation so having a
use statement inside an if conditional is wrong.
On Fri, Aug 15, 2008 at 6:02 AM, Robert A. Schmied <ras
AT
acm.org> wrote:
> Thomas Weigert wrote:
>>
>> I would suggest you do something along the following lines:
>>
>> eval 'Date::Manip;';
>> if ($@) {
>> # do whatever when Date::Manip is installled
>> } else {
>> # handle situation when Date::Manip is not available
>> }
>>
>> Th.
>>
>>
>> Robert A. Schmied wrote:
>>
>>> gt'ers
>>>
>>> i'm thinking the current use Date::Manip statement in GT/Tools.pm is
>>> still
>>> going to fail if you don't have Date::Manip in your perl @INC list
>>> regardless
>>> the result of the if conditional.
>>>
>>> i also think changing 'use' to 'import' will actually fix the problem.
>>> if anyone can confirm (or deny) this is a working solution post a reply.
>>>
>>>
>>
>>
>
> aloha th.
>
> i'm not sure there's any material difference between
>
> eval 'Date::Manip;';
> if ($@) {
> ...
> } ...
>
> and
>
> if ( eval { require Date::Manip } ) {
> ...
> } ...
>
> other than the variable being evaluated. care to elaborate why you prefer
> the former?
>
>
> but the significance of the query was with respect to 'use' vice 'import'
> with
> the purpose being to avoid compile time errors when Date::Manip is actually
> not
> available.
> -- or is Date::Manip now a prereq for gt? in which case the entire
> conditional
> needs to be reworked ...
>
> it seems that perl will solve/resolve (whatever the proper terminology is)
> any and
> all 'use' statements at compile time, but 'import' statements are deferred
> until
> runtime. in this particular instance the import statement will only be
> evaluated
> depending on the eval statement (either implementation). a runtime error is
> thus
> avoided in the absence of the package, which is the purpose of the
> conditional.
>
>
> ras
>
>
>
>