Dear Rony, This may be the explanation. Indeed „my“ installation now goes into /usr/local/
With the information from Enrico, I have also managed to create a pkg installer using pkgbuild that can install to /usr/local so in principle this step could be added to the build process. There are a number of differences to „my build“ Pkgbuild does not generate the welcome screen, the license info etc whereas my build have all that used to be also in the 4.1.2 installer Pkgbuild modifies the path to add /usr/local/oorexx5.0.0/bin: /usr/local/oorexx5.0.0/lib: /usr/local/oorexx5.0.0/share: /usr/local/oorexx5.0.0/include: Whereas my build (the postinstall script) create symbolic links to those places. My build have a preinstall script that removes an earlier installation in the same place, the pkgbuild does not provide that (yet) @ Eric: Should I try to amend the build process on the Mac mini to include this last step? That would provide an installer also if it is not perfect. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 16.09.2018 um 17:24 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>: > > > On 16.09.2018 11:30, P.O. Jonsson wrote: > ... cut ... >> Regarding the performance I think that would need to be treated in another >> thread. I have created >> a LOT of various builds, also comparing with builds from bsf4ooRexx. I have >> had different builds >> from the same build date testeds where one build reports a tenfold speed >> over the other when you >> run rexxcps.rex. However, using both builds to run real programs (rather >> complex and running for a >> longer time) the „slower“ build performs 20-30% BETTER than the „faster“ >> one, so on MAC >> rexxcps.rex is not conclusive. I suggest to open up a new thread for that >> discussion later, I have >> observed is so many times and on at least 3 different machines that it can >> not be just me messing >> it up. I guess one needs to compare library versions and compiler options >> but later, ok? Getting >> an installer is more important. > ... cut ... > > This may have to do with rxapi on MacOSX to have to be started over and over > again. > > In the past years problems with the rxapi plist file on MacOSX have been > pointed out repeatedly e.g. > cf. the mailing threads with CVBruce's posting on 2010-12-24 who also later > pointed at the core > problem on MacOSX cf. CVBruce's posting on 2011-02-20. In this posting (seven > years ago by now) > Bruce reported at having written a work-around for that problem for rxapi on > MacOSX modelled after > the work around put in place for AIX, but was told that someone would rewrite > it later. > > If I am not mistaken, the ooRexx CMake file causes an > "org.rexxla.oorexx.rxapid.plist" to be used > that points to "/usr/bin/rxapi" whereas the official location (after Apple > banned any non-system and > non-Apple software to be installed into "/usr/bin") should be probably > "/usr/local/bin/rxapi" instead. > > --- > > In any case this MacOSX rxapi problem should be addressed once ooRexx 5.0 > went GA. > > HTH, > > ---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
