-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing Stephan's fix for finding VTK. #125
Conversation
That looks great, thank you. I'll run it through buildbot and attempt to test on various different platforms. |
One query: is |
Experimenting on the college cluster, this appears to give answers of the right form with |
Dear all, If I may chip in, last I checked, some work was required to get Fluidity Regards [*] This statement may be completely out of date. On 13/07/2016 14:51, James Percival wrote:
Dr Angus Creech Research Fellow www.research.ed.ac.uk/portal/acreech2 The University of Edinburgh is a charitable body, registered in |
@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... |
Duly noted, Tim - I do wonder if it's worth the effort to support 2016. Regards On 13/07/2016 15:01, Tim Greaves wrote:
Dr Angus Creech Research Fellow www.research.ed.ac.uk/portal/acreech2 The University of Edinburgh is a charitable body, registered in |
@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. |
Ubuntu Trusty, CentOS 6, and CentOS 7 tests now running. |
The fluidity-dev package in CentOS is missing cmake - I'll push a new version of that and retest. |
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). |
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 :-) |
The RHEL/CentOS builds now have cmake added and are running to test. |
That's a weird mix of successes and failures we're getting. Are the full config.log files available somewhere? |
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. |
9b90271
to
f8ab3fc
Compare
f8ab3fc
to
ab08ec3
Compare
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. |
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.