Hi René, During the build process rexxtry.rex is moved (not copied) from /samples to /bin, so despite being a samples it resides in the directory where the executables are. So it beats me how you can test rexx itself but not rexxtry when they reside in the same place?
That said: the only test I have found related to rexxtry is in Package.testGroup, and it is merely a check that rexxtry can be found, nothing more afaik. Why not move this single test case out of Package.testGroup and make it a test of its own? Maybe more meaningful tests could be made since it is such a vital sample/program? I can do this AFTER I have finished the modifications for running samples test cases on macOS, I am in the middle of testing them (37 new test groups) but I do not want to commit anything that breaks anything else. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 19.02.2021 um 18:05 schrieb René Jansen <rvjan...@xs4all.nl>: > > Yes, but my point is, I don’t want that. I do want the tests to succeed on a > non-installed build. I don’t think being able to find rexxtry.rex is a test > for a working interpreter. If we want to test the lookup facility, we should > specify a file that is, or needs to be on the $PATH. There are lots of other > samples beside rexxtry.rex that are non-essential for the purpose of this > test, which is to determine if a change broke functionality on a platform and > indicate that to the developer. > > But I have the copy now in the test configuration and it is fine. I thought > it better for conceptual integrity and fit-for-purpose to remove the test but > when you all disagree it is no problem; case closed. > > best regards, > > René. > >> On 19 Feb 2021, at 16:44, Rony G. Flatscher <rony.flatsc...@wu.ac.at >> <mailto:rony.flatsc...@wu.ac.at>> wrote: >> >> On 19.02.2021 15:28, rvjan...@xs4all.nl <mailto:rvjan...@xs4all.nl> wrote: >>> Ok, will add it to the path like P.O. suggested and hope that it works. Or >>> will copy it after the build. I think it tests the install process and not >>> the working of the interpreter. >> You can test the existence of rexxtry.rex next to rexx[.exe] by something >> like e.g. >> >> self~assertTrue(SysFileExists(filespec("location",.rexxinfo~executable)||"rexxtry.rex")) >> ---rony >> >>>> On 19 Feb 2021, at 14:55, Rony G. Flatscher <rony.flatsc...@wu.ac.at> >>>> <mailto:rony.flatsc...@wu.ac.at> wrote: >>>> >>>> On 18.02.2021 15:49, René Jansen wrote: >>>>> There is currently only one test case failing on the Linux on Z >>>>> Rockhopper, which is the test for the reachability of RexxTry. This is >>>>> because this is the uninstalled version of ooRexx - the so-called USB >>>>> version. I expect this to fail on other machines where we do not do an >>>>> install, because RexxTry has not been copied from samples to the $PATH. >>>>> >>>>> I want to remove this test, does anyone oppose? >>>> hmm, as "rexxtry.rex" has *always* been put into the location where the >>>> executable rexx[.exe] >>>> resided I would regard this a bug in the USB version you used which should >>>> place "rexxtry.rex" next >>>> to rexx[.exe]. As such the test unveiled this error and I would keep it! :) >>>> >>>> ---rony >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
