On Wed, Dec 5, 2018 at 1:10 PM Rony G. Flatscher <[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]> > 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] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
