Thank you Rony, this pretty much sums it up. Just to clarify one option below:
There exists already a standalone ooRexx installation that I created for use on
a USB stick, all that is needed is a USB stick (or any volume that can be
mounted) with the name OOREXX5. Simply mount ooRexx 5.0.0 USB Build 11492
2018-09-05.dmg from my Dropbox, drag everything over to the USB stick and
change the path. Howto inside the image. No outstanding rights and no files
residing on the target system after ejection.
The USB version is a one-off that can be made at any time but not (yet)
automated from CMake daily build.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
> Am 17.09.2018 um 14:11 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>:
>
> Hmm, maybe we should first clarify that there are two possible installations:
>
> system-wide (the current type of ooRexx installation on all systems)
> pro: single installation for entire system, any user and any program can use
> ooRexx
> needs: sudo/priviledged installation and uninstallation
>
> user-confined (not yet available, but extremely important to be able to do)
> pro:
> installation can run on a stick as well
> ooRexx can be used on otherwise locked systems where the user cannot control
> what gets installed on his machine and what not
> this would be extremely helpful for one owns ooRexx-tool-stick, but also for
> showing off what ooRexx is capable of (thinking of my students who could
> program Windows, MS Office, OpenOffice/LibreOffice, Java, .Net,
> GUI-programming, etc.)
> cons:
> only the user is able to run ooRexx, no one else
> if multiple users have user-confined installations, then currently ooRexx
> will stumble over the single (system-wide) socket port it communicates
> currently with rxapi, if another user has a (long) running ooRexx program
> If a system-wide installation of ooRexx is sought, then it is sufficient to
> link the binaries to /usr/local/bin, /usr/local/lib etc., no matter where the
> ooRexx interpreter got installed to /opt, ~/Application or /usr/local. In
> this case I would install the interpreter to /opt/ooRexx to not clutter
> /usr/local and not make a system wide installation dependent on a
> user-confined directory like ~/Application.
>
> In addition, IMHO:
> A system wide installation should have scripts for relinking its binaries to
> /usr/local in case something went wrong or different installers linked to
> /usr/local, mistakingly replacing an already installed ooRexx version
> (something like "link_to_usr_local.sh"). Also, an installation should have an
> uninstall script ("uninstall.sh") that cleanly removes what its installer
> created.
> The location to install to on Unix-based systems should be the same on all
> platforms to simplify (and to ease) managing the installation: for a
> system-wide installation to /opt, for a user-confined installation to ~ (in
> the MacOSX case maybe ~/Application).
> ---rony
>
>
> On 17.09.2018 11:19, René Jansen wrote:
>> … to elaborate a bit further on that:
>>
>> I use the the cmake target option to install, as I build from source. I have
>> to use that option anyway, because the way cmake (lists) is set up now, it
>> uses a way to set the executable path that sets up ooRexx in the path that
>> is used by brew (in my case: ~/homebrew/bin). I don’t like this because then
>> there are managed programs and their dependencies (by brew) and unmanaged
>> ones in the same directory; this is, in my opinion, not good. Of course,
>> this would change if we got the install into brew and have it all managed.
>>
>> I would extend that point of view to the /Library/Frameworks variant; the
>> fact that Apple installs language processors there, means to me that it is
>> the place for Apple installed language processors. When I need a newer
>> version, as I sometimes do, I check if brew has it and run from there; only
>> when not available I build from source and move the executables to
>> ~/Applications.
>>
>> So I am in favour of the ‘minimally invasive’ option as you call it, but
>> then in ~/Applications and not in the home directory to indicate it is not
>> package manager installed, and to group it with other language packages (for
>> me, SWI Prolog is the most important one, but also Eclipse, NetBeans) that
>> follow this convention.
>>
>> best regards,
>>
>> René.
>>
>>
>>> On 17 Sep 2018, at 10:46, René Jansen <rvjan...@xs4all.nl>
>>> <mailto:rvjan...@xs4all.nl> wrote:
>>>
>>> Hi P.O.,
>>>
>>> I install in ~/Applications/ooRexx5.0.0/bin/rexx on nearly all my macs. I
>>> found that several packages I use moved to this location, ~/Applications;
>>> it plays well with the changing ‘system integrity’ policies and makes for
>>> an easy uninstall. Also, I think one should not require Admin rights to
>>> install a personal language tool in a personal directory on a machine;
>>> neither should one force other persons on the same machine (if applicable)
>>> to run the same release.
>>>
>>> I find myself running from Docker containers more and more nowadays, where
>>> I just run the .rpm or .deb, but the native install on Apple goes in
>>> ~/Applications.
>>>
>>> best regards,
>>>
>>> René.
>>>
>>>> On 16 Sep 2018, at 19:16, P.O. Jonsson <oor...@jonases.se>
>>>> <mailto:oor...@jonases.se> wrote:
>>>>
>>>> What is the "right" place for installing ooRexx on a Mac?
>
> _______________________________________________
> 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
