Contrary to what Rick states I proposed the change for CMake for the Mac section to also use the (IMO correct) Shebang #!usr/bin/env rexx. I did not provide a patch but a bug report but the proposal was turned down by Rick because he insisted on a special shebang for Mac, different than the rest. Just read the conversation in Bug #1573
Together with Erich and René I have been spending an entire week setting up an automated test facility for ALL platforms (Mac, Win, Raspberry PI in addition to Ubuntu Linux, more to come) since the current Jenkins master is on the verge of breaking down. Before that I spent all my free time during two weeks writing test cases for ALL sample files. They will be contributed when I have time to merge them with the other tests. All in all I think the MAC users in the community have been chipping in where they can (consider Enricos and Ronys contributions just to mention two). I also think that the tone is getting less than acceptable now so I will not be participating in any further discussions on this list for a few days. Hälsningar/Regards/Grüsse, P.O. Jonsson [email protected] > Am 05.12.2018 um 19:09 schrieb Rony G. Flatscher <[email protected]>: > > On 05.12.2018 15:08, Rick McGuire wrote: >> Seriously, it would be way better to confine your emails to a single topic >> so that all of this stuff does not get propagated in thread replies. > Hmm, thought I keep all related information in one e-mail to ease getting an > overview on the current state on Apple, will split up such postings in the > future. > > ... cut ... > > On Wed, Dec 5, 2018 at 8:54 AM Rony G. Flatscher <[email protected] > <mailto:[email protected]>> wrote: > >> Ad shebang: on Mac after "make" and "make install" will read, e.g. in >> rexxtry.rex: >> #!$<IF:$<PLATFORM_ID:Darwin>,/Users/rony/Applications/ooRexx5.0.0,/usr>/bin/rexx >> >> This looks like a syntax error in the setting of the variable >> CMAKE_INSTALL_PREFIX. This should not be including the $IF part. >> Running "./rexxtry.rex" from a current build directory therefore would only >> use rexx from the directory of the user who created the MacOS version, in my >> case "/Users/rony/Applications/ooRexx5.0.0 ". >> >> CMAKE_INSTALL_PREFIX is intended to be the place where the package is going >> to be installed. Making it based on the user doing to the build is wrong, >> and should be fixed. >> >> >> Also using the ooRexx Rexx programs in a distribution (like in BSF4ooRexx) >> would not allow them to be run in the Unix style from the command line or by >> double-clicking them on the Linux Explorer/Finder would cause these Rexx >> programs to not be executed, but rather generate an error. >> >> That is obviously not the intended result, but a syntax error. >> >> Question: is there a cmake-option that I can set to also have the shebang >> "#!/etc/env rexx" on a MacOS production in order to avoid that pitfall for >> the users? Which one would that be and would it be possible to supply it in >> the cmake step on the commandline in order to not have to edit the trunk >> version of CMakeLists.txt? Trying to define that value on the command line >> with >> >> This should not be in the command line, but rather conditional logic in the >> CMake configuration (as I already explained to PO in a previous email and he >> declined to provide a fix). If someone who works on a Mac develops a patch >> and submits it, it will be considered. I'm getting tired of the Mac >> community asking the none-Mac users to make all of the changes. > The reason for me to have a) Windows, b) Linux and c) Apple is simply to have > all systems available to create and maintain the external ooRexx function > library BSF4ooRexx for them. Everything else in BSF4ooRexx is portable to > wherever ooRexx and Java are available and can be developed and maintained on > a single system. > > BSF4ooRexx regarding c/c++ is a single file, so I have had no need of using & > learning autotools or CMake or the like (and have been saving the needed > time to learn these systems being constantly short of time, not because of > lack of interest). Of course, if I can help on those platforms to improve > ooRexx, I have been doing that. Having said that, currently I have no > knowledge about CMake to be able to take on CMake related problems in an > estimable, finite amount of time and am therefore dependent on hints and > advice, hence posting my observations and asking questions. > > Given that getting ooRexx on all platforms, compiling and testing is a *very* > time-consuming effort and is meant to support the ooRexx project, I hope that > these efforts get appreciated. Unfortunately, currently I have null/zero time > to go out and learn everything in detail that is needed to configure and > compile a (really great, but of course very) complex project like ooRexx > (even learning CMake at this point in time is time wise not possible for me). > The main reason for this is of course that I do have a quite demanding (and > as a result often very time consuming) day job. Still, I have been trying to > allocate as much time as possible to help debug/improve also the ooRexx > project. [The scarce time resources during the day are also the reason why I > would have to work into the nights or on weekends, if possible at all, to > help out in good faith. BTW, that is also the reason why many times I am also > forced to work on BSF4ooRexx in the evening, on the weekends or during > University vacations where the students are away.] > > --- > > Ad the shebang line: > > My understanding about the shebang on Unix (i.e. Linux or Mac) has been that > in the course of its evolution the preference to hard coded paths to > executables has been offset by making it more flexible using /usr/bin/env > to locate the program to execute the script with. Hence the standard shebang > line should probably read: > #!/usr/bin/env rexx > This way it is very easy and simple to have different versions of ooRexx > installed in different directories, switch to any of these directories and > e.g. issue (on Unixes), something like: > PATH=.:$PATH rexxtry.rex > Alternatively, one could add the current directory in the front of the Unix > PATH variable and as a result become able to issue from within any directory > where there is an ooRexx interpreter installed: > rexxtry.rex > The above statement then would work in Windows and Unix. > > A system wide installation of ooRexx on Unix already will find "rexx" as the > standard Unix PATH will have at least /usr/bin, /usr/lib and on MacOS > /usr/local/bin, /usr/local/lib, such that the standard shebang line > "'!/usr/bin/env" will serve its purpose for ooRexx well. > > *However*: one open question about parallel installations and executions of > different ooRexx interpreters would be whether this already can work > flawlessly, if ooRexx got installed system wide? Which libraries will > ooRexx load and use, which binaries? My understanding is that currently > ooRexx uses PATH to find its binaries and libraries and on Unix implicitly > (for the libraries) in addition "/usr/lib" respectively "/usr/local/lib", > such that currently this seems not to be possible. > > In order to employ different ooRexx interpreters at the same time ooRexx > would need to use the binaries and libraries (relative) from its current > installation directory (very much like Java does, if not mistaken) and only > use PATH (and system defined library locations on Unix) as a fallback. > > This way, if merely supplying a fully qualified path to the desired ooRexx > interpreter "rexx[.exe]" to execute an ooRexx program would work! (Also, > having PATH point first to the desired ooRexx version's directory would then > allow one to execute exactly that ooRexx version without any undesired, > potentially problematic side-effects!) > > Among other things this would allow e.g. ooRexx application developers to > distribute their compiled ooRexx programs with the exact version of ooRexx > the ooRexx application got developed and tested with in a standalone fashion! > > ---rony > > > _______________________________________________ > 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
