Re: [Oorexx-devel] Thinking about reorganizing the code tree

[Rick M. <obj...@gm...>]

There's one dependency, unfortunately, that can't be totally
eliminated.  The macro space apis need to call the interpreter to
translate the loaded macros into an internal image.  This does require
a call to rexx.dll.  The new rewrite code, however, dynamically loads
the rexx library and resolves the API it needs to call.  This
hopefully will resolve the cross dependency issues.  rexx.dll will
have static dependencies on rexxapi.dll, but not the other way around.

Rick

On Sun, Jul 27, 2008 at 11:30 AM, David Ashley <da...@us...> wrote:
> All -
>
> There is one other item that needs to be remembered about any reorg.
> Currently there are dependencies between rexx.dll and rexxapi.dll. Neither
> one can be loaded as a stand alone library. The Fedora developers have
> complained about this before. It makes it impossible to load the libraries
> except via the loader program which can resolve such dependencies. All other
> tools can not resolve such interdependencies (ldd, dlopen API, etc)
>
> We need to resolve this problem if only to make it easier to debug stuff
> ourselves.
>
> Oh, the new sockets based library may resolve this problem all by itself. I
> just want to make sure we eliminate the problem.
>
> Thanks,
> W. David Ashley
> IBM Systems and Technology Group Lab Services
> Open Object Rexx Team
> Mobile Phone: 512-289-7506
>
>
> "Rick McGuire" ---07/26/2008 07:00:58 AM---Now that I'm porting the
> rxapi/rexxapi code from 4.0 back into trunk,
>
> "Rick McGuire" <obj...@gm...>
> Sent by: oor...@li...
>
> 07/26/2008 07:00 AM
>
> Please respond to
> Open Object Rexx Developer Mailing List <oor...@li...>
>
> To
> "Open Object Rexx Developer Mailing List"
> <oor...@li...>
> cc
>
> Subject
> [Oorexx-devel] Thinking about reorganizing the code tree
> Now that I'm porting the rxapi/rexxapi code from 4.0 back into trunk,
> I'm starting to think we need to organize the code a bit.  Focusing
> for a moment on just the core pieces, we have 3 main executables.
> These are rexx.dll (forgive me for using the Windows terminology),
> rexxapi.dll, and rxapi.exe.  I'm going to discuss this in terms of the
> code these are executables are built from, which tends to suggest an
> organization.  Because of the rewrite, there's a bit of code sharing
> going on between these components, so our current organization is
> going to be somewhat non-optimal.
>
> For the rexx.dll, this is totally contained in the kernel
> subdirectory, with the exception of some small bits of code in lib and
> the API header files in api.  The lib directory could easily go away
> with a reorg...and I'd be happy to see it go.  Of the two header files
> still in there, one can easily be eliminated entirely, and the other
> likely belongs elsewhere anyway.
>
> Under the kernel directory is a platform subdirectory, with windows
> and unix branches.  In the plaform directories, there's two types of
> code.  The first type is code that implements facilities on behalf of
> the internpreter and is fully cognizant of the interpreter code.  The
> second category is code that implements interpreter-independent
> abstractions of system factilities.  SysFile and SysSemaphore are in
> that category.  The new rexxapi.dll and rxapi.exe code will depend on
> this second category, so it should reside somewhere else.
>
> For rexxapi.dll, there's multiple categories of code used:  1)  Code
> that implements the APIs and the client-side of the API code,  2)
> Access to some system facilities such as SysFile and SysSemaphore, 3)
> access to system facilities that are specific to the rexxapi.dll
> function (similar to the platform code used in kernel), and 4)
> classes that are used both by rexxapi.dll and rxapi.exe.  This code is
> platform independent, but are shared classes that define the data used
> to pass messages back and forth between the client and the server.
>
> rxapi.exe has the same categories as rexxapi.dll.
>
> This seems to suggest the following organization:
>
> kernel (rename to interpreter maybe?) - Contains the interpreter code,
> plus all interfaces to interpreter specific platform facilities.
> Pretty much as it is today, but with classes like SysFile and
> SysSemaphore moved elsewhere.
>
> lib (maybe a different name) - Contains code that can be used by any
> component.  This can contain both platform-independent and
> platform-dependent code, using the standard platform organization.
>
> rexxapi - all code used to implement both rexxapi and rxapi.  This
> will be organized into client and server subdirs (names open for
> debate), plus a "shared" subdir for code that is used by both.
>
> As an additional cleanup, I'd love to see the rexxutils subdirectory
> reworked so that each extension (rxsock, rxmath, rexxutil) has it's
> own directory organization.
>
> Thoughts?
>
> Rick
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>