Implementing Stephan's fix for finding VTK.

[jrper]

This pull request attempts to implement @stephankramer's cmake based fix for finding where the elves have hidden VTK on an arbitrary system, issue #113. So far it doesn't remove anything, the only time it might change behaviour is when cmake isn't available, but the location of VTK has been implicitly provided through environment flags.

[tmbgreaves]

That looks great, thank you. I'll run it through buildbot and attempt to test on various different platforms.

[stephankramer]

One query: is -DCOMPILER_ID=gcc appropriate when using intel?

[jrper]

Experimenting on the college cluster, this appears to give answers of the right form with -DCOMPILER_ID=gcc regardless of the compiler which was actually used to compile the vtk library itself. I think that in this case this only controlling the syntax of the output, and -I/vtk/include/stuff and a list of absolute library paths works for both gcc and intel (plus clang). Do we actually claim to support any other compiler?

[ghost]

Dear all,

If I may chip in, last I checked, some work was required to get Fluidity
to compile with the Intel compilers*.

Regards
Angus

[*] This statement may be completely out of date.

On 13/07/2016 14:51, James Percival wrote:

Experimenting on the college cluster, this appears to give answers of
the right form with |-DCOMPILER_ID=gcc| regardless of the compiler which
was actually used to compile the vtk library itself. I /think/ that in
this case this only controlling the syntax of the output, and
-I/vtk/include/stuff and a list of absolute library paths works for both
gcc and intel (plus clang). Do we actually claim to support any other
compiler?

Dr Angus Creech

Research Fellow
Institute of Energy Systems
University of Edinburgh
Scotland

www.research.ed.ac.uk/portal/acreech2

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[tmbgreaves]

@jrper - we currently only claim support for gcc and Intel 2015.

@anguscr - all working nicely for Intel 2015 now :-) 2016 is another story on many counts...

[ghost]

Duly noted, Tim - I do wonder if it's worth the effort to support 2016.

Regards
Angus

On 13/07/2016 15:01, Tim Greaves wrote:

@jrper https://github.com/jrper - we currently only claim support for
gcc and Intel 2015.

@anguscr https://github.com/anguscr - all working nicely for Intel
2015 now :-) 2016 is another story on many counts...

Dr Angus Creech

Research Fellow
Institute of Energy Systems
University of Edinburgh
Scotland

www.research.ed.ac.uk/portal/acreech2

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[stephankramer]

@jrper: Fair enough - I could imagine though that this might depend not only on the specific compiler but also the environment that was used to built VTK, but I'm perfectly happy to go with the assumption this works in general until such time that we do find a platform where asking for the specific compiler seems necessary.

[tmbgreaves]

Ubuntu Trusty, CentOS 6, and CentOS 7 tests now running.

[tmbgreaves]

The fluidity-dev package in CentOS is missing cmake - I'll push a new version of that and retest.

[jrper]

There's an argument that we ought to be testing this in the case that cmake isn't present as well as the case that it is (in fact it doesn't seem to be present in the trusty build on buildbot either, so the new code shouldn't be doing anything apart from adding a few error messages to the logs).

[tmbgreaves]

I guess the problem arises that when you have the libraries in non-standard places/names it won't find them unless cmake gives useful information. This feels to me to be a reasonable failure, and expected on CentOS since one of the reasons we started down this route was that CentOS had non-standard VTK library naming -- hence I think it's not unreasonable to require cmake to help out :-)

[tmbgreaves]

The RHEL/CentOS builds now have cmake added and are running to test.

[jrper]

That's a weird mix of successes and failures we're getting. Are the full config.log files available somewhere?

[tmbgreaves]

I'm attempting to replicate them by hand at the moment to get the config out - but getting oddly inconsistent behaviour. I think I've done something interestingly wrong.

[tmbgreaves]

There was one minor bug with an additional _ creeping in as CPP_FLAGS (vs CPPFLAGS) which I've fixed and squashed. This builds fine now on CentOS 6, CentOS7 [0], and xenial with vtk5.10, and if one small bug in the libproj package is fixed (softlinking libproj.so) it works with xenial with vtk6.2.

Hence looks good to merge.

[0] The CentOS 7 build is a bit creaky - cmake returns a broken set of include flags for VTK, breaking the automagic (-I//include/vtk instead of -I/usr/include/vtk) but since the subsequent detection looks for the CentOS naming scheme for vtk libraries, the configure and build end up working.