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]> 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]> > *Sent:* den 5 december 2018 21:54 > *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 > > > > > > 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 > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Foorexx-devel&data=02%7C01%7C%7C18ccde003b8949c2848c08d65af3d094%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636796400551582820&sdata=Q708wj%2FX7sdbj6vB0kt%2BPfgyex7u0eLb1EiKC3kRxGM%3D&reserved=0> > > _______________________________________________ > 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
