Dear René, I remember to have pointed out that I see no possibility to automatically create an installer for ~/Applications, i.e. into the users private Applications folder, since we have no knowledge of the username at compile/build time.
I just found out that echo $(whoami) produces the user (po in my case). Could that be built into an automated process, preferably CMake? Just an idea. Von meinen Macbook gesendet Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 16.11.2018 um 00:12 schrieb René Jansen <rvjan...@xs4all.nl>: > > We’ll have look at it. Obviously we only like to script in Rexx, but we’ll > have to make due with what we got. With the .dmg approach, it cannot be hard. > > René. > >> On 15 Nov 2018, at 18:53, Rick McGuire <object.r...@gmail.com >> <mailto:object.r...@gmail.com>> wrote: >> >> >> >> On Thu, Nov 15, 2018 at 5:35 PM P.O. Jonsson <oor...@jonases.se >> <mailto:oor...@jonases.se>> wrote: >> If that is a HARD requirement and it turns out Apple removed those items we >> need then what? >> >> You obviously have not taken a look at what we did for Windows. CMake has >> ZERO support for the Windows NSIS installer, but we are able to build the >> installer bundle completely in CMake using the CMake configuration >> information to build the installer. CMake is as much a scripting language as >> it is a configuration, including the ability to invoke external programs. >> For Windows, we use the information created by the various CMake install() >> commands to build the appropriate install manifests needed to buld the NSIS >> installer, and then build the installer all from within CMake. As I have >> been telling you over, and over again, you should be able to do something >> similar for the Mac, regardless if there is any native support in CMake. >> >> Rick >> >> >> >> I agree that as much as possible should be made from one source but if the >> reality changes … Please remember that there is currently NO official >> installer at all (not even for version 4) that is working on MAC. >> >> I promise to look into what can be done for CMake (I have the 700+ page book >> in front of me on the desk) but until now I did not succeed. >> >> @Enrico: can you provide any help here? I am illiterate in CMake still. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> Am 15.11.2018 um 23:26 schrieb Rick McGuire <object.r...@gmail.com >>> <mailto:object.r...@gmail.com>>: >>> >>> >>> >>> On Thu, Nov 15, 2018 at 5:03 PM P.O. Jonsson <oor...@jonases.se >>> <mailto:oor...@jonases.se>> wrote: >>> Dear René, >>> >>> In principle I have (almost) all the steps ready to do a .dmg installer, >>> with some limitations. I did not manage to get it all controlled from CMake >>> but would an afterburner shell script be so bad? >>> >>> I would not find it acceptable. We did not spend all this time getting a >>> uniform build process only have have it split off before 5.0.0 even >>> releases. All of the locations and artifacts used to build the installer >>> needs to come from the Cmake configuration information. That is a HARD >>> requirement. >>> >>> Rick >>> >>> >>> CMake <complex command> >>> make >>> make install >>> bash afterburner.sh >>> >>> There are ways around sudo password >>> >>> https://discussions.apple.com/thread/4469969 >>> <https://discussions.apple.com/thread/4469969> >>> >>> And I would expect that on a machine with a strong password for remote >>> login (my ooRexx Mac mini) used by a single user (Jenkins) for the sole >>> purpose of building ooRexx such use would be acceptable, security wise, or >>> do you disagree? >>> >>> Using this method it is possible to create the entire chain of commands set >>> out above without any user interaction. I have tried it out on my own >>> machine and it does work (but is a bad idea for permanent use on a „normal“ >>> user account, I know). >>> >>> Personally I have nothing against two or more „official" ooRexx installers, >>> one for /opt, one for ~/Applications and the BSF4ooRexx installer (but that >>> might suffice to link to). For the two first I think I can do a dmg >>> installer but bear with me for a week or so, I am quite busy with non-oo >>> stuff and I also want to finalize the test cases for the sample files (and >>> test them). >>> >>> Regarding Jenkins Master I have offered the T20 Windows machine as a host >>> (test is up&running at http://jonases24.asuscomm.com:50000/login?from=%2F >>> <http://jonases24.asuscomm.com:50000/login?from=/>) but on second thoughts >>> I think it might be bad idea to have the Jenkins Master on a physical >>> machine needing maintenance and support. I have virtually no knowledge on >>> how to manage the environment where Jenkins is currently running and I >>> think a rented server/cloud solution would be a safer and more stable >>> situation. The T20 could then be used to host the slave for Windows 10 >>> 32/64 or whatever is needed. But if you find time to do a test please give >>> it a try, the machine is not used for anything else. >>> >>> Hälsningar/Regards/Grüsse, >>> P.O. Jonsson >>> oor...@jonases.se <mailto:oor...@jonases.se> >>> >>> >>> >>>> Am 15.11.2018 um 17:17 schrieb René Jansen <rvjan...@xs4all.nl >>>> <mailto:rvjan...@xs4all.nl>>: >>>> >>>> I agree, but as said before, I think it was Rick, we need an automated Mac >>>> installer that is integrated into the CMake build lists. >>>> >>>> One way to accomplish that is to move forward the no-admin version, we >>>> could then just automate building a .dmg with the materials on it, to move >>>> to a suitable location - ~/Applications comes to mind. When there is >>>> knowledge of scriptable installer builders, we need to use that. Since I >>>> made the first Mac installers with the awkward dialogs and scripts a lot >>>> has changed. I will communicate with P.O. and Enrico and see what can be >>>> done. >>>> >>>> I still need to move the Jenkins to a place where it keeps working and >>>> then we can release from there and upload to SF. I will try to put >>>> together a checklist on the wiki on SF (it has one doesn’t it). When we >>>> have worked on that, we’ll need to confer with Erich and Rick, and branch. >>>> >>>> >>>> best regards, >>>> >>>> René. >>>> >>>> >>>>> On 15 Nov 2018, at 10:17, Rony G. Flatscher <rony.flatsc...@wu.ac.at >>>>> <mailto:rony.flatsc...@wu.ac.at>> wrote: >>>>> >>>>> This past year there have been many remarkable changes (performance >>>>> improvements from 1.2x to 20x >>>>> times, memory management, multi threading) and additions (ADDRESS...WITH, >>>>> variable references) to >>>>> ooRexx 5.0 beta, which already was great with respect to valuabel and new >>>>> features a year ago! >>>>> >>>>> Judging from my work on BSF4ooRexx and ooRexx projects, ooRexx 5.0beta >>>>> has become stabler, faster >>>>> and more versatile than the almost five years old ooRexx 4.2.0 (release >>>>> date: February 2014). >>>>> >>>>> Therefore, I think, it is time to create a release version of ooRexx >>>>> 5.0beta, such that companies >>>>> and organisations become able to install and take advantage of it! (As >>>>> long as software is dubbed >>>>> "beta" it usually does not get deployed for professional purposes in >>>>> organisations.) >>>>> >>>>> So I suggest to create a branch 5.0.0 which does not take any new >>>>> features anymore, just bug-fixes >>>>> and materials to complete it (e.g. test units, documentation) "as fast as >>>>> possible". (Any new >>>>> features would go to trunk only and could be used to create a 5.1 version >>>>> shortly after the release >>>>> of 5.0.) >>>>> >>>>> ---rony >>>>> >>>>> P.S.: After the release of 5.0 I would really suggest to create a version >>>>> 5.1 as soon as possible >>>>> thereafter, which allows ooRexx to be run without administrative >>>>> privileges on Windows, Linux and >>>>> MacOSX! >>>>> >>>>> P.P.S.: There are many important additional features for ooRexx post 5.x >>>>> like Unicode-support, now >>>>> that even English versions of Windows create Unicode text files by >>>>> default, let alone international >>>>> users of ooRexx with a need for support for their culture's glyphs (also >>>>> speeding up/simplifying >>>>> interfacing with Unicode-systems like Java, applications employing >>>>> Unicode for which ooRexx should >>>>> serve as a scripting language, but also operating systems like Linux, >>>>> MacOSX and Windows). Or >>>>> getting a NetRexx like catch-finally construct, or ... much, much more! :) >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
