Dear Rony, Sorry for the lagging replies; I am away from my computers and only check my mail every now and then.
Short recap of the terminology for the non-Apple users: macOS <https://en.wikipedia.org/wiki/MacOS> is what the current GUI and operating system for Apples computers is called. Darwin <https://en.wikipedia.org/wiki/Darwin_(operating_system)> (or DARWIN) is the Unix dialect upon which macOS is built. Darwin was inherited from NeXT and is the reason macOS is more related to Linux/Unix when it comes to building ooRexx. A „Bundle <https://en.wikipedia.org/wiki/Bundle_(macOS)>“ is a concept in macOS with a specific structure. On a Mac all applications are normally stored as Bundles in the /Applications folder A „Framework <https://en.wikipedia.org/wiki/Bundle_(macOS)#macOS_framework_bundles>“ has the same (or similar) structure a a Bundle, but is is stored in the (for the user invisible) /Library/Frameworks. Version 3 of Python installs itself as a Framework as do Bsf4ooRexx. A „Package <https://en.wikipedia.org/wiki/Package_(macOS)>“ is a simpler concept than a Bundle or a Framework. I quote: "In the Apple macOS <https://en.wikipedia.org/wiki/MacOS> operating system, a package is a file system directory <https://en.wikipedia.org/wiki/Directory_(file_systems)> that is normally displayed to the user by the Finder <https://en.wikipedia.org/wiki/Finder_(software)> as if it were a single file.“ My proposed installer of ooRexx for macOS creates a Package. <snip> > The reason why I would like to discuss the location of the system wide > installed ooRexx interpreter is simple: if I know where to look for a system > wide ooRexx installation I could adapt the BSF4ooRexx installer such, that it > would only install its ooRexx, if no ooRexx is available on the Apple > machine. This would add the benefit for ooRexx that indeed an Apple > Applications bundle gets added with an application that merely creates the > Apple task bar and makes e.g. the documentation available to the user (in > addition to the BSF4ooRexx menu items). > From the above it is clear that it would be correct „Applish“ to install ooRexx either as a Framework (as BSF4ooRexx is currently doing it) or as a Bundle in the /Applications folder. - This is not possible without creating a pkg installer (I know of no way to include pre- and postinstall flights otherwise), which in its turn forces the use of 3rd party installer building tools, like Packages <http://s.sudre.free.fr/Software/Packages/about.html> I have done this in the past manually, and it is mind-boggling and unintuitive. It can be done (Rony is proof of that) but any single tiny change and you are back at square one. - I have tried, and failed, to script Packages, Without a command line version of Packages it will not be possible to automate the builds. - Installing a Framework forces the use of „Sudo“, i.e. it will not be usable for those who need to use ooRexx without elevated rights. - We introduce the dependency of yet another 3rd party Application (Think Publican). -The uninstaller is a command line exercise (and we must provide it to the user so that it is available to him if he want to uninstall ooRexx). Installing to another place, like /opt or /usr/local will also automatically force the use of elevated rights (sudo) when creating the (many) symlinks). > A system wide installation needs links from the ooRexx bin and lib files to > /usr/local/bin and /usr/local/lib which is as simple as preceeding the link > commands with "sudo" (which will ask the user for the appropriate > credentials, if the installer itself does not have them acquired already). > > This is not completely true. What I propose (and have shown a mockup of) can be seen as a Package in Applish. If the user clicks the ooRexx Icon it will show the documentation, the License and the internal structure (/bin, /lib etc). The only requirement for ooRexx to run (fully and completely, including man pages, sample files, documentation etc) is that the /bin folder is in the path (/Applications/ooRexx5/bin for instance). Once that is assured no further links (also not to the /lib folder) are necessary after Enrico´s brilliant contribution. The Package created is truly sudo-free and universally relocatable. The further advantage of this (besides being installable even on a USB stick and uninstallable by a drag&drop) is that you can have as many versions of ooRexx as you desire, the switching requires only a single change to the path. I reiterate: The dmg installer I have created contains of a number of straight forward system commands and introduce no 3rd party dependencies. It can be run as an „Afterburner“ to the normal build steps. This is what I do locally and could easily provide for Jenkins. Should something else be desired I urge anyone to step forward and pick up the baton. > ---rony > > > > On 20.08.2020 22:25, P.O. Jonsson wrote: >> Dear Rony, >> >> The installation we have today for macOS have the internal Unix structure >> but can be moved anywhere as long as the ooRexx5/bin is in the path. There >> is absolutely NO need to create symbolic links for ooRexx to work. This is >> the reason why it is possible to do a dmg installer using simple shell >> commands, all tools that are needed to create the package are already >> present on the build machine. >> >> My proposal was to enable the move of the package to /Applications as a >> directory cloaked as an app. >> >> In „Appleish“ this is not strictly an app (the internal structure is >> different) but I see no real problem in moving the package to /Applications, >> if the user wants to uninstall ooRexx all s/he needs to do is a single >> drag&drop to the garbage bin. If someone considers me to be a „bad“ Apple >> citizen so be it :-) >> >> As soon as you talk about „Frameworks“ or „Bundles“ in Appleish you force >> the use of a proper pkg installer with all the overhead (pre- and post >> install scripts, .plist files and many many symlinks that needs to be >> created). And, since Apple does not foresee a proper way of uninstalling >> stuff from the GUI (here, for once, Windows has an advantage) you not only >> need to create an uninstall script, you forces upon the user the necessity >> of using a sommand-line shell script. >> >> Further, since Apple have removed the possibility to create pkg installers >> from the command line, we are forced to script 3rd party installer creation >> apps from CMake. I have tried this a number of times and given it up. >> >> If the general opinion is that we cannot just move the (Unix-like) package >> into /Internal, it ends here as far as I am concerned; I cannot help with an >> installer having all the niceties that you write about below. >> >> Maybe the better option would be to reach out to the people creating >> installers (and uninstallers) for all kind of stuff (mainly Homebrew and >> Ports). They should be able to create the necessary symbolic links since the >> installation can run from anywhere, also from /usr/local/cellar (Home-brew) >> or from /opt/Local (MacPorts). >> >> Here a mockup of how „my“ dmg installer looks like >> >> <ooRexx5 Installer on macOS.png> >> >>> Am 19.08.2020 um 11:39 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at >>> <mailto:rony.flatsc...@wu.ac.at>>: >>> >>> Dear P.O., >>> >>> firstly, *any* official installer for MacOSX is fine with me! :) >>> >>> In principle there are two different approaches on the Mac, using a) the >>> Unix structures (having "bin", "lib", etc.) or using b) Apple's Developer >>> bundle structures which define how Applications and Frameworks bundles >>> should be structured (an brief overview of bundles can be seen >>> here:<https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1> >>> >>> <https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1>). >>> >>> Ad a) using the Unix conventions >>> >>> here the next question is, where to put "ooRexx". Currently the directories >>> are 1) "~/Applications" and 2) "/Applications". 1) would be probably o.k., >>> because a user can do anything on his home directory, 2) would be >>> problematic as currently your installation is not an "Application bundle". >>> If I am not mistaken, you need to link to "/usr/local/bin" and >>> "/usr/local/lib" in case 2)? >>> >>> The Unix convention seems to be to install such structured applications >>> from third parties to "/opt" which is also the case for Apple. So my >>> suggestion would be, if one installs ooRexx systemwide for the Mac, then >>> install it to "/opt/ooRexx" and creating the necessary links to >>> "/usr/local" as usual. >>> >>> Ad b) using the Apple conventions (which the BSF4ooRexx installer does), >>> which probably is not needed and complicates everything for the goal to >>> become a "native Apple citizen" :) >>> >>> The Apple world revolves around "Frameworks" for code that is to serve >>> multiple applications and used to build applications and tools. The Apple >>> XCode uses frameworks to simplify supplying the libraries an >>> application/tool needs to link to. ooRexx would fall under this category, >>> hence a need to create a "Frameworks" bundle (cf. >>> e.g.<https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/IncludingFrameworks.html> >>> >>> <https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/IncludingFrameworks.html>) >>> >>> The "Applications" bundles are meant for - Applications and must contain an >>> application by the same name as the Applications bundle without the ".app" >>> extension! It is possible to use Info.plist to define that application (in >>> BSF4ooRexx cf. the keys "CFBundelExecutable" and "CFBundleIdentifier" and >>> environment). >>> >>> As a result your ooRexx installer for MacOSX is *not* an Apple Application >>> bundle and therefore should not be placed into any folder that is named >>> "Applications" as this would be misleading on Apple. Rather I would suggest >>> either "/opt/ooRexx" (for a systemwide installation with appropriate links >>> to "/usr/local") or "~/opt/ooRexx" (plus updating the user's PATH >>> environment variable). >>> >>> ---rony >>> >>> P.S.: The plain-vanilla BSF4ooRexx installer (the zip-file) for Windows and >>> Linux is also able to install on the Mac. It will install itself to >>> "/opt/BSF4ooRexx" there as well. (As in the past there were no installers >>> for ooRexx 5.0 beta I created with the help of students the Apple bundle >>> structure conforming installer.) >>> >>> >>> >>> On 18.08.2020 23:27, P.O. Jonsson wrote: >>>>> Am 18.08.2020 um 14:11 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at >>>>> <mailto:rony.flatsc...@wu.ac.at>>: >>>>> >>>>> Dear P.O., >>>>> >>>>> On 17.08.2020 22:51, P.O. Jonsson wrote: >>>>>>> Question ad Apple/Mac (Darwin) >>>>>>> >>>>>>> CMakeLists.txt overrules the CMake default and explicitly installs to >>>>>>> "set (CMAKE_INSTALL_PREFIX $ENV{HOME}/Applications/ooRexx${ORX_MAJOR}" >>>>>>> (cf. CMakeLists.txt, line # 247. This means that no system wide >>>>>>> installation of ooRexx is done. >>>>>>> >>>>>>> Question 2 (Apple question): should the default installation be to >>>>>>> /usr/local, such that by default a system wide installation takes place >>>>>>> like on Linux? >>>>>>> >>>>>> Personally I think /usr/local would be illogical for macOS (DARWIN). On >>>>>> macOS there is no need to „install“ ooRexx 5. Thanks to Enrico it can >>>>>> run from anywhere without any installation step. For this reason I think >>>>>> it would make sense to treat it as any other „App“ on macOS. >>>>>> >>>>>> The current agreement is to put the ooRexx 5 package in the users >>>>>> Applications directory ~/Applications (in my case in >>>>>> /Users/po/Applications), this comes with some disadvantages: >>>>>> (i) the user may need to create ~/Applications (it is not there on a >>>>>> pristine system) >>>>>> (ii) the user need to amend the path >>>>>> (iii) the installation is for that one user only. >>>>>> (iv) to uninstall ooRexx the path needs to be restored again >>>>>> >>>>>> My proposal would be to put the installation in /Applications, where >>>>>> virtually all applications reside that are installed by the user. This >>>>>> would mean that all disadvantages (i)-(iv) would go away automatically. >>>>>> >>>>>> It would further provide a well recognized method of >>>>>> installing/uninstalling, a simple drag&drop to the garbage bin would be >>>>>> sufficient to remove every trace of ooRexx. Since /Applications is >>>>>> already in the path also the man pages work as expected. >>>>>> >>>>>> I have already made a post-build script (driven by Cmake) that produces >>>>>> a dmg installer that looks exactly like the installers provided by any >>>>>> regular „app“, with the familiar drag&drop functionality, also including >>>>>> the documentation, license etc. If there is an interest I can show a >>>>>> mockup (I do not have access to the >>>>>> real thing from where I am now). >>>>> Yes, this would be much better IMHO! >>>>> >>>>> Do you distinguish between "/Library/Frameworks" and "/Applications" >>>>> locations as the Apple developer guide suggests? >>>>> >>>> Nope. The installation ends up in subfolder ~/Applications/ooRexx5 >>>> >>>>> >>>>> The "/Library/Frameworks/ooRexx.framework" locations should be used for >>>>> the binaries and include files (e.g. >>>>> "ooRexx.framework/Versions/A/Libraries/librexxapi.3.dylib" ... >>>>> "ooRexx.framework/Versions/A/Headers/oorexxapi.h" >>>>> ..."ooRexx.framework/Versions/A/Commands/rexx"...). Then link "Libraries" >>>>> to "Versions/Current/Libraries" and the like for "Commands", "Headers", >>>>> "Shared“. >>>>> >>>> There is no need to complicate things :-) While this is true for a >>>> „Framework“ it is not necessary for ooRexx to work as it is set up now. >>>> The current setup is more similar to a „Bundle“ in that there is no need >>>> to link it to other resources. ooRexx5 is self contained. This is how the >>>> folder structure looks like on a standard installation: >>>> >>>> /Users/noob/Applications >>>> └── ooRexx5 >>>> ├── bin >>>> ├── include >>>> ├── lib >>>> └── share >>>> ├── man >>>> │ └── man1 >>>> └── ooRexx >>>> ├── native.api >>>> >>>> This is very similar to Linux in that the bin, lib, include and share are >>>> all at the same hierarchical level. >>>>> The binaries should then be linked to "/usr/local/bin" and the libraries >>>>> to "/usr/local/lib" which makes them systemwide available, hence ooRexx >>>>> can be deployed from everywhere. >>>>> >>>>> >>>> >>>> Again, there would be no need. Changing >>>> >>>> set (CMAKE_INSTALL_PREFIX $ENV{HOME}/Applications/ooRexx${ORX_MAJOR}“ >>>> >>>> To >>>> >>>> set (CMAKE_INSTALL_PREFIX $ENV/Applications/ooRexx${ORX_MAJOR}" >>>> >>>> Would automatically make ooRexx available system-wide, since /Applications >>>> is in the path by default on macOS. >>>> >>>>> >>>>> The "/Applications" directory would contain some "ooRexx.app" folder, but >>>>> would need some program that offers a GUI via which one e.g. could get >>>>> access to the sample and pdf help files. >>>>> >>>>> >>>> Nope. It is very simple to cloak the ooRexx5 folder (programmatically!) as >>>> an app folder and add for instance the documentation and license. I am >>>> already doing this in the ooRexx 5 dmg installer I was talking about >>>> earlier. >>>>> --- >>>>> >>>>> If the official ooRexx gets installed into /Library/Frameworks" I could >>>>> adapt the BSF4ooRexx installer for Mac to then only install the >>>>> "/Applications/ooRexx.app" folder which I then might rename to >>>>> "/Applications/BSF4ooRexx.app". Currently BSF4ooRexx includes ooRexx as >>>>> in the past there was no working ooRexx installation package anymore, it >>>>> includes a small Java application which creates the Mac menu bar with all >>>>> sorts of folders and programs (comparable to Windows), such that the >>>>> sample and pdf help files become easily accessible by the users. >>>>> >>>>> >>>> >>>> I strongly object to installing standalone ooRexx as a „Framework“ This is >>>> not only complicated but also need a fully fledged sudo pkg installer, >>>> with pre-and post install scripts, I have done it in the past and it was a >>>> true PITA. >>>> >>>> Please also realize that the internal structure of a „Framework“ is >>>> entirely different to the default installation (see above) and Linux, >>>> making references to for instance the samples different compared to Linux >>>> or the current structure of macOS. If >>>> filespec('Location',.rexxinfo~executable) provides >>>> >>>> /Users/noob/Applications/ooRexx5/bin >>>> >>>> all I need to do to locate the samples would be this: >>>> >>>> /Users/noob/Applications/ooRexx5/bin/../share/ooRexx >>>> >>>> And it would be the same for Linux and macOS. >>>> >>>> Now, for a „Framework“ installation the names of the subfolders are >>>> different and will need further testing. >>>> >>>> Moving the Whole Shebang from ~/Applications to /Applications (without ANY >>>> other modifications) would be the best option in my opinion. >>>> >>>> Here a mockup of how the installation would look like to the user. > > _______________________________________________ > 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
