Tested using Perl, included a file containing.
use strict;
use constant CURR_PROJ => 0;
and sub routine definitions.
No errors or problems.
============================
Schwa, Justin, Chris,
This is a significant change and to some extent will make it much easier to share code with others and to re-use subroutines etc.
However, and please don't think I'm unappreciative of the work involved and the speed of development, I don't think this step is in the right direction.
RPR_include() will work to an extent but doesn't address some basic issues and will eventually cause more issues with code sharing than it solves.
Each variable and subroutine declared in the included file share the same name-space as the main script - so you will get variables in the main script inadvertently being given the same name. Each included file pollutes the main script's name-space and that problem will get worse the more code is shared (it will get worse as ReaScript gets more popular)
The ideal way to implement ReaScript in Perl would be the same way the FFI module is implemented. A short .PM file and a DLL. To use Perl within REAPER you would simply say:
And the RPR module would provide access to the REAPER routines, using FFI, as REAPER does now.
This would be a far cleaner way of implementing ReaScript in Perl:
- user written modules (.pm files) would be able to call RPR routines
- users would be able to provide each other with vastly simplified methods for accessing REAPER objects
- user written modules would have their own name-spaces - variables and sub names would not collide.
Again, please don't think I'm unappreciative or moaning because things aren't "just-so". But please do look again at the basic FFI mechanism and consider implementing it in a .dll invoked by a .pm. Looking at the way it's implemented at the moment (that means guessing, just so you know
) I suspect that you have the guts of the code you need already - that is the routines that use FFI to call REAPER functions.