yes, but very probably CMake has a symbolic for that too. But yes, everything that works from within CMake.
René > On 16 Nov 2018, at 09:36, P.O. Jonsson <oor...@jonases.se> wrote: > > 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 <mailto:oor...@jonases.se> > > > >> Am 16.11.2018 um 00:12 schrieb René Jansen <rvjan...@xs4all.nl >> <mailto: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 >> <mailto: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
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
