> Am 24.01.2021 um 21:44 schrieb Rick McGuire <object.r...@gmail.com>: > > > > On Sun, Jan 24, 2021 at 3:30 PM P.O. Jonsson <oor...@jonases.se > <mailto:oor...@jonases.se>> wrote: >> Am 24.01.2021 um 18:11 schrieb Rick McGuire <object.r...@gmail.com >> <mailto:object.r...@gmail.com>>: >> >> >> >> On Sun, Jan 24, 2021 at 11:11 AM P.O. Jonsson <oor...@jonases.se >> <mailto:oor...@jonases.se>> wrote: >> >>> Am 24.01.2021 um 12:39 schrieb Rick McGuire <object.r...@gmail.com >>> <mailto:object.r...@gmail.com>>: >>> >>> P.O., you have commit privileges now, so you ARE a developer. >> >> I only used those privileges for documentation purposes, but if you are fine >> with it I will contribute what I did. >> >>> If you have an install process working that is working through CMake >>> working, then it should be checked into the project. Having something that >>> is your private setup is not a working solution. You could be hit by a bus >>> tomorrow, >> >> Regarding bus accidents: this is indeed one weak spot in the project: the >> whole Jenkins business (setup scripts, addresses, PWs etc) is backed-up >> locally and the information is spread on a few hands but there should be >> some mechanism to secure it on Sourceforge, which is lacking today. Moving >> Jenkins last time was a major effort with a lot of tweaking. I suggest to >> rename the „buildmachine“ item in the documentation back to „oorexxbuild“ >> and start documenting all aspects of the build process there. Last time this >> was done was in 2012 it seems. oorexxbuild, the earlier name (and internal >> name used as well) appears more logical than buildmachine, it is not about a >> machine rather all aspects of building ooRexx. >> >>> so our ability to build an installer would go away. Having an installer >>> available means any interested person can checkout the code and follow the >>> instructions to build it themselves. >> >> Regarding an installer for macOS: The currently available „official“ >> installer, 4.1.2 (on RexxLA and Sourceforge) was introduced late 2012 and >> stopped working late 2015 with the introduction of SIP in macOS El Capitan. >> It has been broken for five years by now, I do not think that can be >> considered „Gold“ can it? >> >> I reverse-enigeered the 4.1.2 pkg-installer and fixed the installation >> problem by moving the installation from /usr to /opt and created a new >> installer. I had to make it a command-line installer since the pkg build >> option did no longer work on macOS, but it is pretty straight forward. I >> also created uninstaller scripts for version 4, something that was missing >> all the time. This installer was offered to the project but never accepted. >> Available here >> <https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0> >> >> I have no knowledge on how to upload anything to sourceforge other than to >> the build trunk, so if the installer for V4 is accepted can someone please >> put it in the right place? >> >> No, the correct place would be to check it in to the source tree, as all >> other critical items are. Follow the lead of what was done for Windows. >> Files needed to build the installer are in trunk/platform/windows/install. >> There should be an equivalent directory created for the Mac. > > OK, I will put everything used for the installer in > trunk/platform/unix/macosx/ once I have confirmed that the 3 files residing > there are obsolete and not used anywhere in Cmake. Currently I refer to local > files but this will be easy to amend once it is agreed to go ahead. >> >> Also, I want to make clear that this is only acceptable if you have >> addressed the CMake integration issues. I'm not sure you really understand >> the requirement here. By integrated, I mean that all artifact files are >> defined only in the project cmake file, and then cmake makes the adjustments >> to pick up the build artifacts. > > OK, I admit I am not quite there yet, but I am working on it. > >> >> So, to be clear, let's assume I add a new xyz.cls file to the project (or a >> new library file, sample, whatever). All I need to do as a developer is to >> make the appropriate additions to the cmake file, including adding an >> "install" definition to the cmake file. Your integration for the Mac >> installer should update whatever install artifacts need to generate the >> installer automatically. > > It does. > >> If a developer needs to directly alter any of the Max installer files, this >> is not acceptable. This was one of the primary reasons we switched to CMake >> in the first place, to get away from having different makefile and installer >> requirements for the different platforms. > > Any modification to the source code will be picked up by the installer, since > it is a step AFTER the "build install“ step, i.e. the installer is built from > an existing and working installation in the default position, currently > ~/Applications. > > I am not referring to modifications to the source files, that is just > business as normal. I am referring to what happens when new components are > added to the build, such as new .cls files, new libraries, new doc files, > etc. The install statements in the CMake file determine what items need to be > picked up to generate the installation package on all platforms without > requiring the developer adding the component to understand the details for > any of the platforms involved. The mac version needs to do this as well. > > Rick
AFAIK it does, since the creation of the installer only „wraps“ an existing installation, an installation that is tested just the same way as it has always been tested, using the test framework. There is a section at the very end of Cmakelists #Apple macOS if (MACOSX_BUNDLE) … In Cmakelists.txt that might need further attention since it is most likely obsolete. It is currently not used (on Jenkins) as it is not working correctly. I have tried to invoke it but it creates empty installer files. Of the 3 files in trunk/platform/unix/macosx/ only org.rexxla.oorexx.rxapid.plist is referred to in Cmakelists.txt, in this section. > > > The only problem I see here is that the post-build installer creation > presumes the installation to be in ~/Applications, so a Cmake change to where > the installation resides might break the build of the installer. > > I have modified the build process on Jenkins to build the installer now, be > aware that this is a draft version, I do not know where to put the installer > Artifact (the dmg file) so I have put it temporarily in ~/workspace/ on > Jenkins macOS slave. Look at the build steps on Jenkins to see if this is > somewhat acceptable. > > Please note that the local „make install" ooRexx is identical to the previous > ooRexx installed and the testing takes place using that installed ooRexx so > everything is the same as before, except we now have a dmg installer item in > addition. > >> >> >> Same for version 5 of the installer, I can arrange for it to be built on >> Jenkins automatically but for uploading it to the right place >> (/projects/oorexx/files/oorexx/5.0.0beta/?) I think you or Erich need to >> amend the upload script on Jenkins. >> >>> >>> That would be a big step, but the docs really need a thorough review. A lot >>> of new features in 5.0 (e.g., variable references) make portions of both >>> the reference and programming guide a bit dated. >>> >>> There are currently 83 open bug reports. A few of these I would consider >>> show stoppers, such as Walter's linein performance problems and the issues >>> with Windows file name case. A number of others are not in complete state, >>> missing needed tests and documentation. There are similar incomplete items >>> in the feature requests. This is not a release that is ready to go gold >>> yet. >> >> I for one would be happy if we could get „Silver“ on the road and provide >> „Gold" in 5.1. Please document the showstoppers for all others to see and >> judge. Help may arrive from unexpected places and showstoppers for some may >> not be showstoppers for others :-) Since the GC was rewritten ooRexx 5 >> improved greatly and is IMO already „Gold“. I have scripts running for weeks >> now that do not bloat, they just go on and on and on. If we document the >> items that are still (for some) showstoppers, that would be sufficient for >> me. Example: I do not suffer from Walters performance problems, I could work >> around it using arrayIn instead, fast like a wind. >> >>> >>> Rick >>> >>> On Sun, Jan 24, 2021 at 5:54 AM P.O. Jonsson <oor...@jonases.se >>> <mailto:oor...@jonases.se>> wrote: >>> I agree with Rony that version 5 of ooRexx should be formally released, I >>> just did not raise my voice since this is a discussion amongst the >>> developers. >>> >>> Due to the delay we may already have lost a major „client, my former >>> employer, the European Patent Office, with more than 4000 ooRexx 4 >>> installations. They are now going all-in for Python instead, they will >>> never be able to upgrade to 5.0.0 unless there is an official release. >>> >>> Can Rick and/or Erich provide a list of „showstoppers“ so they can be >>> worked off? Are there REALLY any problems that are so severe that they >>> would prohibit a release? I doubt it. >>> >>> I can offer to set up the macOS Installer on the Jenkins machine. It is >>> Cmake driven and uses standard Unix commands in the post-processing. It >>> also includes the latest documentation, license, HowTo etc. Example can be >>> found in „MacBuilds“ here >>> <https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0> >>> >>> I have also written test cases for all sample files, they can be uploaded >>> but require a little fix in the testing framework (that I can provide as >>> well). >>> >>> I have set up the documentation (PDF and HTML) to be built on Jenkins every >>> new revision (this is where I get it for the macOS installer) what is >>> missing is an upload to Sourceforge, this needs to be done with someone >>> with R/W access there. >>> >>> So what is really missing that prohibits a release? Is it not about time >>> now to kill our baby and go ahead and release 5.0 and start working on 5.1? >>> >>> Hälsningar/Regards/Grüsse, >>> P.O. Jonsson >>> oor...@jonases.se <mailto:oor...@jonases.se> >>> >>>> >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> Oorexx-devel@lists.sourceforge.net >>>> <mailto:Oorexx-devel@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <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
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
