> Am 16.11.2018 um 14:51 schrieb Rick McGuire <object.r...@gmail.com>: > > 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 <rvjan...@xs4all.nl > <mailto:rvjan...@xs4all.nl>> 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 <oor...@jonases.se >> <mailto: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 >>> <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
