Closed JackPerdue closed 5 years ago
@JackPerdue The problem is that the Python bindings for OpenColorIO
are built by default (but without proper checking whether python-devel
is installed).
Simplest solution is to disable building of the Python bindings (and only build them when Python is included as a dependency), done in #7416 .
I'm working on a better setup to test PRs in an isolated minimal environment, where stuff like python-devel
is not available. But we recently noticed that this is not perfect either, since sometimes problems only pop up when stuff is installed in the OS, see for example https://github.com/easybuilders/easybuild-easyblocks/issues/1608.
So in a perfect world, we test both on a minimal system where as little stuff as possible is installed, yet also test on a real production system where things like zilb
, Boost
, python-devel
& much more are installed.
That's certainly not impossible, but it's an extra effort to maintain these environments, and implies spending (even) more time on testing incoming contributions... Note that the test builds are not done using Travis, only the unit test suite (which checks for stuff like missing dependencies, conflicts, etc.) is run there.
closing this since Python bindings in OpenColorIO
are now disabled via #7416, so no Python.h
needed in the system anymore
EB3.8.0/CentOS7.5
OpenColorIO/1.1.0-foss-2018b fails to build due to lack of Python.h.
The sloppy workaround is install python-devel. But that sucks as a solution and if its the proper one then the .eb needs to add an osdep=python-devel at least.
I really would like to see a full listing of RPM/packages in the Travis "test" environments. I don't see how this could have passed without python-dev(el) being installed. Ideally the test beds would have NO -devel packages to avoid problems like this (except when explicitly listed as an osdep). This happens far too often. The EB testbeds really should be stripped to a minimum if they really want to do a proper test.