Ensure that the tests find the built python module vs an install #4411
Conversation
…lled one This may have a slightly messy un-intended consequence of "snap-shotting" pythonpath when configured in a large python env, but eases testing confusion on systems where pythonpath is not yet set, but an (older) copy of OpenImageIO is installed. Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
src/cmake/testing.cmake
Outdated
| @@ -110,6 +110,7 @@ macro (oiio_add_tests) | |||
| "OIIO_TESTSUITE_ROOT=${_testsuite}" | |||
| "OIIO_TESTSUITE_SRC=${_testsrcdir}" | |||
| "OIIO_TESTSUITE_CUR=${_testdir}" | |||
| "PYTHONPATH=${CMAKE_BINARY_DIR}/lib/python/site-packages:$ENV{PYTHONPATH}" | |||
There was a problem hiding this comment.
Does the fact that you used : here account for the Windows CI failures?
There was a problem hiding this comment.
most likely, switching to use generator expression which should be fine in cmake 3.14+ - the pathListSep config variable is not available until 3.24 or somesuch
Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Also adds python version and init.py to build tree such that windows has a chance of working with the DLL loading Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
|
With the latest commit, I can cleanly run the test target from the build folder (assuming I have previously downloaded the test images) without running an install, which eases the development workflow. I do not have a windows machine to test with, but windows (and ninja multiconfig) have multiple configs, so to avoid potential slicing, put the python modules in the appropriate config path - and copied the init.py in there such that it might work to load the dlls under windows (untested). Given that the CI runs the tests using the installed dist tree, I have disabled overriding the env variables in this scenario |
| if (NOT DEFINED ENV{OpenImageIO_ROOT}) | ||
| # this will ensure the appropriate fonts are found | ||
| set_property(TEST ${_testname} APPEND PROPERTY ENVIRONMENT | ||
| "OpenImageIO_ROOT=${CMAKE_SOURCE_DIR}/src") | ||
| endif() |
There was a problem hiding this comment.
I'm not 100% sure I understand all the implications -- now or after future changes we aren't considering -- of setting OpenImageIO_ROOT to point to the src directory, of all places.
And what happens if somebody is building in an environment where OpenImageIO_ROOT is already set to someplace other than this build area (maybe to an existing install)? In that case, this would not be set, and what would that mean?
Wouldn't it be more direct to set OPENIMAGEIO_FONTS to exactly the right spot? And much less likely to affect absolutely anything else?
Also, sorry about this nit, but would you mind using 4-space indentation like the surrounding code? Thanks.
lgritz
changed the title
This may have a slightly messy un-intended consequence of "snap-shotting" pythonpath when configured in a large python env, but eases testing confusion on systems where pythonpath is not yet set, but an (older) copy of OpenImageIO is installed.
This fixes the python tests on my home machine.
Checklist:
(adding new test cases if necessary).
corresponding Python bindings (and if altering ImageBufAlgo functions, also
exposed the new functionality as oiiotool options).
already run clang-format before submitting, I definitely will look at the CI
test that runs clang-format and fix anything that it highlights as being
nonconforming.