> Am 24.02.2021 um 18:15 schrieb Erich Steinböck <erich.steinbo...@gmail.com>: > > > is the Windows testing supposed to be running from the build directory > > rather than from the installation? > Yes, on Windows we run tests directly from the build. > The test job just adds the build directory to its PATH, like this > set PATH=..\..\ooRexx-windows64-build\oorexxBuild\bin;%PATH% > This was just done because it's simple. It would be beneficial if we ran the > installer, but I'm not sure whether this can be done in a headless mode. > We actually never test that the install works (neither do we on Unix-like > systems - see below) > > > are we to assume that a build takes precedence on other platforms? > > Currently all other tests (with the exception of IBMZ) takes place on > > installed ooRexx. > Not sure what you mean here.
What I mean is that in order to test the samples one needs to know if the samples in a build dir takes precedence over samples in an install dir or vice versa. This text in FileUtils.cls seems to imply that an installed ooRexx should take precedence over an ooRexx in the build dir: /** locateSamplePrg() * Locates a sample program normally shipped with the ooRexx distribution. * * The sample is searched for in the location(s) for samples programs in a normal * install. If it is not found, an attempt to find it using the assumption that * the test is being executed from within a build directory. This second search * allows the test suite to be run by a developer from his build directory * without having a regular install. * * @param name REQUIRED * The name of the sample program. * * @return The complete path name of the sample if it is located, otherwise * .nil. */ ::routine locateSamplePrg public use strict arg name <…> This is the same for all OSes and I have confirmed that it works this way (and I wrote macOS to work this way as well). Since we do a "make install" for macOS and all *nix this means we are always testing the latest built samples for those platforms. Now here comes the Crux: On Windows (on Jenkins) we have 3 different ooRexx: one installed (obsolete 32 bit version) and a 32 bit build and a 64 bit build in parallel structures. Since the priority is Install before Build the testing of the samples on Windows take place on an obsolete set of samples and hence failed when I had updated the code of one sample. This was the reason for my original question. I do not know how to solve this, it works as intended for macOS and all the *nix (after some mending) but Windows I cannot fix without violating the rule above. > Like on Windows we don't run the installer, but use `make install`, which is > a kludge, as it can never be properly uninstalled. > Same as above: it would be beneficial to run (and thus test) the installer. I agree that it would be great to confirm that the installer actually works but I have no idea how to do that, not for macOS, not for *nix and certainly not for Windows. > > _______________________________________________ > 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
