And just to be complete I DID post a patch to this list: On Wed, Nov 7, 2018 at 5:01 PM P.O. Jonsson <[email protected] <mailto:[email protected]>> wrote: Dear Rick and Erich,
I have tried today to build on MAC using revision 11517. Unfortunately the Shebang comes out as #!/opt/oorexx5.0.0/bin/rexx rather as the intended #!/usr/bin/env rexx I copied the line set (OOREXX_SHEBANG_PROGRAM "/usr/bin/env rexx") To the Unix part of CMakelists.txt and after that I get the expected Shebang in all examples I have created a diff file and attached it (as well as my version and r11517. Hälsningar/Regards/Grüsse, P.O. Jonsson [email protected] > Am 05.12.2018 um 20:05 schrieb P.O. Jonsson <[email protected]>: > > 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] <mailto:[email protected]> > > > >> Am 05.12.2018 um 19:09 schrieb Rony G. Flatscher <[email protected] >> <mailto:[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] >> <mailto:[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
