Here's what the recommend for determining the current user: https://cmake.org/pipermail/cmake/2012-October/052301.html
On Fri, Nov 16, 2018 at 9:14 AM P.O. Jonsson <[email protected]> wrote: > > Am 16.11.2018 um 14:51 schrieb Rick McGuire <[email protected]>: > > I want to clarify something here. The CMake configuration needs to be used > to build the installer, not BE the installer, so questions of how to > determine the userid to use is a function of the installation program, not > something you would determine at installer build time. > > > In order to make an installer for ~/Applications it is necessary to define > the installation directory at the time CMake is run, hence the question to > René > > > There are just a few criteria I would define for this: > > 1) No developer that is adding a new install artifact (new library, .cls > file, sample, etc.) should ever have to update anything other than the > CMakeList.txt file. If they need to also make an update to a Mac-related > file, then this is a failure. > > > Agree completely > > 2) Creation of the installer needs to be managed either automatically as > part of the platform build or as a separate make target for the build. The > various Linux flavors are handled the first way, Windows is handled the > second way, > > > I understand that you want that (although I see a 3rd alternative for > builds that are stable, the manual build as for Bsf4ooRexx). > > > The resulting installer/uninstaller can be built using any method you > choose as long as it meets the criteria above. > > > The problem I had was to „transplant“ an installation made for > ~/Applications (i.e.physically in /Users/po/Applications) to another user > (oo), I got error messages when trying to use the installed ooRexx > installation I got runtime errors. -> to be investigated > > > Rick > > > On Fri, Nov 16, 2018 at 8:38 AM René Jansen <[email protected]> wrote: > >> 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 <[email protected]> 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 >> [email protected] >> >> >> >> Am 16.11.2018 um 00:12 schrieb René Jansen <[email protected]>: >> >> 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 <[email protected]> wrote: >> >> >> >> On Thu, Nov 15, 2018 at 5:35 PM P.O. Jonsson <[email protected]> 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 >>> [email protected] >>> >>> >>> >>> Am 15.11.2018 um 23:26 schrieb Rick McGuire <[email protected]>: >>> >>> >>> >>> On Thu, Nov 15, 2018 at 5:03 PM P.O. Jonsson <[email protected]> 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 >>>> >>>> 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 >>>> [email protected] >>>> >>>> >>>> >>>> Am 15.11.2018 um 17:17 schrieb René Jansen <[email protected]>: >>>> >>>> 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 <[email protected]> >>>> 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 >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>>> >>>> _______________________________________________ >>>> Oorexx-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
