On Fri, Feb 19, 2021 at 1:19 PM P.O. Jonsson <oor...@jonases.se> wrote:
> 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?
>
This test belongs exactly where it is because is is a test of the
functionality of the Package class, not of rexxtry itself.
Rick
>
> 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>
> wrote:
>
> On 19.02.2021 15:28, 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>
> <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
> 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
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
