Re: [Oorexx-devel] A strategy for non-core classes.

[Mark M. <mie...@gm...>]

On 3/18/07, Rick McGuire <obj...@gm...> wrote:
>
> I think in the near future, the number of classes shipped with ooRexx will
> grow.  Currently, all of the automatically located classes are included in
> the saved rexx.img file.  As we add classes to that image, it starts to
> grow to very a very large size.  This size is overhead that all programs
> that use ooRexx will pay.  I think we need to start moving some of these
> less-core classes into external files that must be ::requires'd for use.



That makes a lot of sense to me.


  It would be nice if we could come up with a search order step for these
> files that are independent of the current directory or path setting ( i.e.,
> are in a directory relative to the ooRexx install).  It also would be nice
> if we could also define an extension directory in "user space" where users
> could place their own class packages without requiring modification to the
> interpreter install.
>
> For the first, I'm not sure what ability we have on the different
> platforms for determining the location of the rexx executables.  This might
> require an environment variable to give us to the pointer to the location.
> I'm open to suggestions on how to manage this.  The more portable the
> solution, the better.



On Windows the Microsoft C run time library provides a global variable that
points to the fully qualified location of the executable.  I'm not sure if
that is a standard C run time feature or a Microsoft addition.  If it is a
standard than that would work for programs started using rexx.

But, not for someone starting the interpreter from within there own
application.  I would think there is a way to find out the fully-qualified
name to rexx dynamic link library on Windows, but I'm not sure about on
Linux.  Especially if a symbolic link is involved.  (And when I say Linux, I
am really assuming that something that does or does not work on Linux would
work the same on other Unix's.)

An environment variable is portable and reasonable, but a little more
fragile than if we could determine the installation location of the rexx
executable absolutely.  For instance, the user could delete the environment
variable.


For the user data, some of the tools I use in my "day job" have a convention
> that works fairly nicely.  These tools look for a "." prefixed directory in
> the user space that used for user-specific data.  For example, the maven
> tools I use create a ".m2" directory for each user.  On unix, this directory
> is ~/.m2.  On Windows, this directory is created in the user "Application
> Data" directory.
>
> So, it would be nice to create a .oorexx/requires directory into which
> user packages can be placed.  Part of my thinking here is we might
> eventually have a configuration file in this directory that can be used to
> add additional search paths, preload packages, function libraries etc.



Yeah, I think that convention works fairly well.  I used to think it did not
fit well in Windows, but no longer.  As more and more cross platform
applications use the convention, it makes sense to me on Windows also.
Subversion is another example that follows the convention.  It seems the
right approach to me.

--
Mark Miesfeld