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.
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. 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, The resulting installer/uninstaller can be built using any method you choose as long as it meets the criteria above. 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
