On 29/08/2018 13:52, Paul Melis wrote:
Hi,
A related question after Caspar and I figured out yesterday the
situation described below: how come Blender failing to build wasn't
caught in the release testing? I seem to remember that before each EB
release put in the wild all easyconfigs are built (automatically) at
UGent to find errors and regressions. I that something I misremembered?
Automatically is a big word here...
The regression testing isn't fully automatic yet, or not enough to my taste.
This problems didn't slip through the cracks though: the Blender
easyconfigs in the central repository still build fine, because they
don't include CUDA as a dependency...
The easiest to fix that is to contribute back the Blender easyconfig
where you are seeing this problem.
regards,
Kenneth
Regards,
Paul
On 29-08-18 12:15, Caspar van Leeuwen wrote:
Dear all,
I've been trying to compile Blender with CUDA support. We had a
working EasyConfig in our local repo (see attached), which recently
broke. It now produces the error:
In file included from
/scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/intern/ghost/intern/GHOST_ContextGLX.h:41:0,
from
/scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/intern/ghost/intern/GHOST_WindowX11.cpp:51:
/scratch/shared/jenkins/regression/build/Blender/2.79b/foss-2017b-Python-3.6.3-nvidia/blender-2.79b/extern/glew/include/GL/glxew.h:1758:29:
error: expected initializer before
<E2><80><98>glxewInit<E2><80><99>
GLEWAPI GLenum GLEWAPIENTRY glxewInit ();
We found out the problem occured since we had recompiled our
CUDA-9.0.176 module. It now prepends the 'extras/CUPTI/include'
directory to the CPATH, since a change in the CUDA EasyBlock about a
year ago or so. This path unfortunately, also includes (rather old) GL
headers. The reason is probably that those are used by CUDA to compile
its examples, but they mess up our installation process for Blender. A
manual install, where we take out this path from the CPATH, worked.
My question is: how should we solve this?
1) Don't have the CUDA module prepend extras/CUPTI/include CPATH
(upside: old GL headers are not picked up anymore. Downside, the
actual CUPTI headers for profiling are also not picked up so user
would have to include these manually).
2) Have the CUDA EasyBlock remove (just) the old GL headers from the
extras/CUPTI/include path (downside: not default CUDA installation,
examples may not build. Upside: you can leave CUPTI headers in CPATH)
3) 'hack' the Blender EasyConfig (or a Blender EasyBlock) to do a
tricky thing to get extras/CUPTI/include out of the CPATH, e.g. in the
prebuildstep or something. Upside: CUPTI headers can remain prepended
in CPATH in the CUDA module, and the CUDA examples will build 'out of
the box'. Downside: feels very dirty and other software MAY run into
the same, old GL headers.
What's your opinion? Which option is best? Or is there another, better
option?
Cheers,
Caspar van Leeuwen
SURFsara
