I expect you test if your commits will pass.
From: Rick McGuire <[email protected]> Sent: den 5 december 2018 22:19 To: Open Object Rexx Developer Mailing List <[email protected]> Subject: Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang And yet, you don't include the errors so a fix can be made. I'm not in the mood for people throwing shade today :-( Rick On Wed, Dec 5, 2018 at 4:11 PM Håkan Erixon <[email protected]<mailto:[email protected]>> wrote: Astonished that you will fix problem without a bug report (PASE compile) and in the same time complain about other reports. FYI can’ t compile latest commit because of rexxutil.cpp for windows changes From: Rick McGuire <[email protected]<mailto:[email protected]>> Sent: den 5 december 2018 21:54 To: Open Object Rexx Developer Mailing List <[email protected]<mailto:[email protected]>> Subject: Re: [Oorexx-devel] Ad shebang, parallel installed ooRexx interpreters running concurrently (Re: revision 11569, MacOS, question ad shebang On Wed, Dec 5, 2018 at 1:10 PM Rony G. Flatscher <[email protected]<mailto:[email protected]>> wrote: 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. \Starting an email with a subject line about shabangs with pages of warning messages does not qualify as related infomation. It is just noise for any discuss related to the subject of the email, particularly since the bulk of the information is a repeat of stuff you have already sent off. ... 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. Funny how I am expected to learn about and have access to every platform though. If nobody with a vested interest in running on the Mac is willing to step up and take ownership of this, then I have no problem with saying I will not provide any support for that platform. I also have a finite amount of time. The strategy of "complain about it until Rick fixes it" has got to end. 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 w eekends 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. Yes, thank you for the wonderful tutorial on the shebang line...I am done with this discussion. Decide what you want to have done and submit a CMake patch for it. Just make sure you don't mess up any other platform in the process. Any yes, this means learning a little bit about CMake. But questions about what is going on in the CMake problem will be answered (to the best of my ability). This goes beyond just the shebang line though, the bigger question is what should the CMAKE_INSTALL_PREFIX be. The line that was added for the Darwin support is clearly wrong. This needs to be the expected install location to be used by an installer and should not be tied to the userid of the person performing the build. Once that is correct, then the shebang line will correctly point to that executable. If you still decide that you want it to be "#!/usr/bin/env rexx" for the Mac, then submit a patch that corrects that, but don't do what PO did and submit a patch that made the decision for every other system. Rick ---rony _______________________________________________ Oorexx-devel mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/oorexx-devel<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Foorexx-devel&data=02%7C01%7C%7Cece0ad8463694a0287ac08d65af7551c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636796415658976039&sdata=n0LcrzCLEuTstFyAE4Uwj%2FJSKEf%2B5FrPjHyRs2afMHA%3D&reserved=0> _______________________________________________ Oorexx-devel mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/oorexx-devel<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Foorexx-devel&data=02%7C01%7C%7Cece0ad8463694a0287ac08d65af7551c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636796415658976039&sdata=n0LcrzCLEuTstFyAE4Uwj%2FJSKEf%2B5FrPjHyRs2afMHA%3D&reserved=0>
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
