in reply to Writing a Perl extension framework for Inkscape

How closely can you control when perl.exe is launched from Inkscape? If it is just a matter of setting up the correct @INC, you can just launch it by setting up the process environment with PERL5INC=(?)/Inkscape/lib/perl. Alternatively you can launch (whatever) Perl.exe with -Mlib=(?)/Inkscape/lib/perl.

Of course, that Perl might be missing some modules, but at least Strawberry Perl comes with XML::LibXML included and you can easily distribute it with Inkscape or as a bundled package with your framework modules.

Replies are listed 'Best First'.
Re^2: Writing a Perl extension framework for Inkscape
by fdesar (Beadle) on Jan 22, 2019 at 14:20 UTC

    Thanks. Be sure I though of that before.

    My own modules start to setup @INC with use dir at their very beginning: that's not the problem, it works pretty well. But each script must do that to load the initial common module: this is not clean.

    AFAIK, Inkscape calls an executable called perl.exe without any parameter. It IS possible to modify this under Unices via a preference.xml file, but this file does not exist in the windows version and I do not have access to the process environment to setup a variable at startup.

    But this is not the real part of the problem: it requires an external Perl installation and Straberry Perl is a fat thing that casual users of extensions definitely don't need (they don't need a Unix environment). This is why the Inkscape Team included Python in their distribution and why I'd like to do the same with Perl. And Active Perl is not, strictly speaking, free software and this I don't like.

    And last but not least, I've always hated this Python vs Perl discrimination ;)

      AFAIK, Inkscape calls an executable called perl.exe without any parameter. It IS possible to modify this under Unices via a preference.xml file, but this file does not exist in the windows version and I do not have access to the process environment to setup a variable at startup.

      The Inkscape documentation for extensions contains a procedure for setting up paths to interpreters which tells how to find where the file is:

      2.Open your perferences.xml file with a text editor (find the exact location of the file by going to Edit -> Preferences -> System: User Preferences)

      The procedure mentions Windows so it leads me to believe this will work on Windows:

      4.Insert a key for the interpreter, for example 'python-interpreter' for setting the program that should be used to run python extensions, and set the string to the absolute path to the python binary which is compatible with Inkscape's current extension scripts (in the example below, the path is "/usr/bin/python2.7". It will look different on Windows systems.):

      In case there is already a version of Perl on the system you could follow the approach that the portable version of Strawberry Perl uses with the portableshell.bat file. Instead of calling a Perl executable file directly you can call the bat file and it sets up a temporary environment with the Strawberry Perl folders at the beginning of the path and then runs perl.exe. This means the modules that are installed with Portable Perl are used instead of the ones installed in the system Perl.

        The preference.xml file does not exist on the windows port. And they don't seem to use neither the registry. Maybe I'm missing something.

        But yes, the idea of using a perl.bat to launch wperl.exe is a very good idea. I though of it but forgot. But I still need a "little" Perl distro for those not interested by Perl itself and I would like to integrate it cleanly into Inkscape... At least, give the users a choice.