in reply to Perl/Tk Version Dependency Issue

It's not possible to use the same Tk for different Perl versions. It's possible, though, to have a separate Tk module for each Perl version, even on the same computer - yes, you can have more than one Perl version installed. See perlbrew, or local::lib. The trick is that each Perl knows where to search for its modules.
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,

Replies are listed 'Best First'.
Re^2: Perl/Tk Version Dependency Issue
by rkabhi (Acolyte) on May 24, 2016 at 09:45 UTC
    Hi Choroba,
    Thanks for your response !!

    Are you sure about this? Usually we may not expect that much of version dependency for any other perl module. Right?

    Even though my observations are same as what you have mentioned, I had difficulty in convincing my manager that Tk perl module is acutually entirely version dependent.

    But in case this is a bitter fact about which you are sure as well, I worry I may have to shift all my perl scripts away from Tk as we cannot have a sustainable script production this way due to high maintenance needs on each and every user's system.

    Looking forward to your reply on this.
      Any module that needs to compile XS code depends on Perl version (and C compiler version and flags). I doubt you can find any GUI module that doesn't depend on them.

      On the other hand, this doesn't mean high maintenance needs. Just ship your application together with the right Perl version, and you'll only have to manage single build of each module.

      Another option is to distribute the sources and dependencies and let the end users compile the modules themselves (by prepared scripts, of course).

      ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,