[Paraview] Troubles building mathstuf/qhull subproject using PV 4.4.0 superbuild with Intel >14.x compilers

[Ben Boeckel]

On Tue, Jan 19, 2016 at 19:05:38 -0700, Giovanni A. Cone wrote:
>     I'm attempting to get PV 4.4.0 builds of Paraview 
> against Intel 14 and 15 on our HPC systems.  One item that 
> some users have asked us for was the Cosmotools integration. 
> This ultimately needs the Qhull library to be built.  Builds 
> against GCC 4.8.2 went through without a hitch.  However the 
> Intel builds all failed with an odd cryptic syntax error 
> message that I do not fully comprehend (sorry I'm still 
> stuck in Fortranistan).
> 
> Building CXX object 
           ^^^

See below.

> CMakeFiles/qhullcpp.dir/src/libqhullcpp/Coordinates.cpp.o
> In file included from 
> /tmp/conega/BUILD/lightshow/paraview-4.4.0-osmesa/intel-15_openmpi-1.6.5/BUILD01/qhull/src/qhull/src/libqhull/poly2.c(16):
> /tmp/conega/BUILD/lightshow/paraview-4.4.0-osmesa/intel-15_openmpi-1.6.5/BUILD01/qhull/src/qhull/src/libqhull/qhull_a.h(106): 
> warning #77: this declaration has no storage class or type 
> specifier
>    template <typename T>
>    ^
> 
> In file included from 
> /tmp/conega/BUILD/lightshow/paraview-4.4.0-osmesa/intel-15_openmpi-1.6.5/BUILD01/qhull/src/qhull/src/libqhull/poly2.c(16):
> /tmp/conega/BUILD/lightshow/paraview-4.4.0-osmesa/intel-15_openmpi-1.6.5/BUILD01/qhull/src/qhull/src/libqhull/qhull_a.h(106): 
> error: expected a ";"
>    template <typename T>
>             ^
>  From what little I understand of C and C++, I believe that 
> "templates" are a C++ construct.  I'm thinking the Intel 
> compiler is attempting to digest the above as "straight-up 
> C" and failing.

Marked above, it is compiling as C++, but it appears that it is trying
to parse template as an identifier rather than a keyword. My guess is
that it is something like:

    struct foo {
        int member;
    } // no semicolon
    template ...

which parses into a function returning a foo struct (declared there as
well) named 'template'.

> The error messages put the blame on 
> QHULL_SRC_ROOT/src/libqhull/qhull_a.h  around line 105
> 
> I then decided to snoop on github.com for another qhull 
> repo.  I found one
> at
> 
> https://github.com/qhull/qhull
> 
>  From which I believe the "https://github.com/mathstuf/qhull 
> next branch" repo that Paraview wants to use was forked from.

Not originally, but it is now that qhull has moved from sourceforge to
github (it was originally forked from George Zegaris' clone which he
mirrored from sourceforge to github, but I recently re-forked the proper
repo).

> Point being that the mainline non-forked Qhull has something 
> different in the preprocessor conditional surrounding the 
> above offensive line of source:
> 
> #if defined(__cplusplus) && defined(__INTEL_COMPILER) && 
> !defined(QHULL_OS_WIN)
> 
> while the mathstuf/qhull repo DOES NOT have the above 
> "defined(__cplusplus)" preproc conditional.

My 'next' branch is based off an old release, so differences to upstream
are not surprising.

> I tested to see if the addition would at least allow the 
> 'mathstuf/qhull next branch' source to properly build with 
> Intel 14 and 15.  It got about to 36% and then failed with 
> the error message:

All my branch does is fix an Xcode compilation errors where std::
iterator tags are forward declared improperly.

> In file included from 
> /tmp/conega/qhull_SRC/src/libqhullcpp/QhullIterator.h(13),
> from /tmp/conega/qhull_SRC/src/libqhullcpp/Coordinates.h(13),
> from /tmp/conega/qhull_SRC/src/libqhullcpp/Coordinates.cpp(11):
> /tmp/conega/qhull_SRC/src/libqhull/qhull_a.h(106): error: 
> this declaration may not have extern "C" linkage
>    template <typename T>
>    ^

It appears that something is doing

    extern "C" {
    #include "qhull.h"
    }

which won't work since qhull is a C++ header. Are there any 'extern "C"'
bits around? Passing -E (or whatever Intel's equivalent is) to dump the
preprocessed source would help to see. The __cplusplus check may be
guarding against that line in upstream.

> So at least the conditional helped a bit for what I believe 
> is the "straight up C" part of the build.
> 
> 
> I'll CC the author of the fork Ben Boeckel about this.

That's me too :) . Seems I forgot to change the author setting for that
clone :/ . Rewrote the commit with the proper email.

--Ben