On Sun, Nov 25, 2018 at 11:36 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:
> Creating ooRexx from trunk from scratch into a new (empty) directory, > which will create the following rxapi-related files: > > - ./bin/rxapi > - ./bin/librexxapi.5.0.0.dylib > - ./bin/librexxapi.dylib -> librexxapi.5.0.0.dylib > > Then doing a "make install" which will use the created interpreter and > installs it to "~/Applications/ooRexx5.0.0". Here the following files with > "rxapi" in their names can be found: > > 1. ./bin/rxapi (Nov 25, 2018) > 2. ./bin/rxapid (Jul 7, 2017: a shell script) <--- ? > 3. ./bin/librexxapi.dylib -> librexxapi.5.0.0.dylib (Nov 25, 2018) > 4. ./share/ooRexx/rxapid.service (Aug 16, 2016) <--- ? > 5. ./share/ooRexx/50-rxapid.preset (Aug 16, 2016) <---? > > So the current installation adds the files 2., 4., and 5. to the > installation directory. > > Definitely, 3. and 4. are outdated for MacOSX as they point to > "/usr/bin/rxapi" which is forbidden nowadays on MacOSX (only Apple is able > to install there, hence "/usr/local" for everyone else). They possibly > cannot work if the path to rxapi is wrong? > I believe all of those are part of the requirements for getting the system to automatically launch the daemon on system startup. It does sound like they are wrong for the Mac and may need adjustment, but I may have a better solution (see below). > > 3. is a bash script by Perry Werneck from 2013 that is based on > "OpenSUSE's" "/etc/init.d/sekeleton.compat". > > So my take would be that the current setup for MacOSX from ooRexx trunk > and CMake actually is wrong/outdated for Mac. Would others agree? > > --- > > Here all "rxapi" related files in the trunk source tree of ooRexx: > > - ./platform/unix/rxapid.service (Aug 16, 2016) > - ./platform/unix/macosx/org.rexxla.oorexx.rxapid.plist (Oct 2, 2018) > <-- only MacOSX related file, but not copied to installation! > - ./platform/unix/50-rxapid.preset (Aug 16,2016) > - ./rexxapi/server/platform/unix/rxapid (Jul 7, 2017) > - ./rexxapi/server/platform/windows/rxapi.ico (Sep 16, 2012) > - ./rexxapi/server/platform/windows/rxapi.rc (Jun 3, 2014) > > So the MacOSX installation should only copy > "./platform/unix/macosx/org.rexxla.oorexx.rxapid.plist" file and ignore all > others? > > --- > > As mentioned in another thread, BSF4ooRexx uses information of the past > years from the ooRexx developer list and uses the plist file > "org.rexxla.oorexx.rxapid.plist" (same as in > "./platform/unix/macosx/org.rexxla.oorexx.rxapid.plist") that defines the > rxapi daemon characteristics and post- and preflight scripts that use > "launchctl" to load or exit the rxapi daemon, which seems to work. > > It is sufficient to have a symbolic link in /Library/LaunchDaemons, > however the owner must be root and the group admin, otherwise (according to > my notes) a launchctl warning gets issued to the effect "launchctl: Dubious > ownership on file (skipping): > /Library/LaunchDaemons/org.rexxla.oorexx.rxapid.plist". > > The command to launch the rxapi daemon is (postflight script after initial > installation): > > launchctl load -w /Library/LaunchDaemons/org.rexxla.oorexx.rxapid.plist > > The command to unload the rxapi daemon is (preflight script before > deinstallation): > > launchctl unload -w /Library/LaunchDaemons/org.rexxla.oorexx.rxapid.plist > > --- > > There are others who have a real and deep knowledge in MacOSX (like Bruce > or Enrico), such that there may be better suited approaches. Maybe they > even could come up with solutions that could be applied to the project? > > I have just started work on a solution that no longer requires a single daemon for the platform but rather use a single process per Rexx user. Right now, I'm working on refactoring the code a bit to make it easier to plug in different management schemes, and the next step will be to convert Windows, which is the version that will require the most new code, then will address the *ix variants after that. I'll need so assistance from somebody on that step as I don't have a Linux setup any more. When this is all done, all of this daemon stuff, including the writing of the PID files should go away and things will get a lot simpler. Rick > ---rony > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
