The bulk of the code restructuring is complete (at least the interpreter portion (nee kernel). The next step is rearranging things into the extensions and utilities directory. My plan right now is that each build artifact should have its own subdirectory in the appropriate place (extensions for a dll or shared library, utilities for a ".exe" or program). The first steps apply to the artifacts where there's an equivalent for all platforms. Thus the extensions directory current has rexxutil, rxsock, and rxmath. The rxsock and rxmath use a single source for all platforms, so it is structured as a single directory. rexxutil has unix and windows versions, so there's the standard platform/* directory structure under rexxutil. The utilities directory has a similar structure.
This leaves open the question of how to handle platform-specific artifacts. Currently, the rexxutils windows directory contains the rxwinsys code, which clearly should be moved. But where? How should we be handling the platform specific stuff? Currently, only windows really has this type of item. The largest bits are located in the platform\windows directory off of the main tree level. Other windows-specific items include rexxhide.exe and rxwinsys, which are scattered in other locations. rexxhide sort of falls in the utilities catetory, while the other items (rxwindsys, oodialog, oleobject, orxscript) would generally fall in the extensions category. I see a couple of options here. 1) We can keep the platform/windows/oleobject, etc. structure we now have, with a single directory per feature. 2) We add platform directories under utilities and extensions and move the existing windows bits around into the appropriate categories...again, with a single directory for each build artifact. The main platform directory would then be used primarily for infrastructure-type items such as install, packaging, build utilities, etc. I'm not sure I have strong opinions either way, although in terms of being able to locate things in a particular category, I think option 2) might work better. Am I missing any other alternatives? 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
