-
Notifications
You must be signed in to change notification settings - Fork 17
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
Cmake and Bilder Issue #51
Comments
This seems like ANOTHER issue I was having with building on Ubuntu 16.04 (see also issue #52 ). Combined, these caused headaches. The FULL workaround to solve both issues was using bilder built CMake, and Ubuntu supplied fftw3 and hdf5. However, now that bilder has updated CMake, as you've found, it looks like we can't do this anymore! |
Here is my CMake output when trying to run it for Puffin. Seems slightly different than Piotr's... |
Thanks for this. I think one approach is certainly to force version 3.4.1 of cmake - which as you've seen can be done either on the command line or via a machinefile for ubuntu 16.04. Piotr's error in this ticket seems to be the one with FFTW not being found. We have put in the fix Lawrence saw for FFTW3 so I think that should also solve this issue. I guess to be sure, I need to check the following: This is a lot of builds, and to be confident each time we need to reboot and use a clean environment. Anyone offering to help??? :) I seem to have started with a few of these, but bilder changes have gone in since then so hopefully all is working better now. I'm trying to separate out what are potentially bilder issues, from issues with scimake/cmake to issues with the packages themselves. #52 looks to be an issue with the fortran libs in hdf5-1.8.18 on ubuntu16, which I believe need patching up as there were some .mod files that weren't getting where they should (At least with intel compilers). see Bilder is mostly building stuff against mpich now, but should be able to switch. It could be that I was not seeing this as I let bilder provide mpich or openmpi instead This does take us to an open question - how many versions of openMPI/mpich and of the other packages do we want to support. The fewer we choose, the easier everything is for us to maintain, but the more people will go "but that's not what I've got on my system". The more, the more test build processes we should be running to ensure these remain working. |
As far as I could tell, some flags were not explicitly set in SciMake, which was causing issues in the latest versions of CMake. They may have changed some default or assumed behaviour. In particular, the flag TFP_ALLOW_LIBRARY_DUPLICATES in SciFindPackage.cmake was causing trouble. I've manually put in an explicit flag in its place, which is absolutely not the best solution for SciMake, but it works for all cases tested in Puffin. Resolved in commit 0cf7789 |
Recently the Bilder updated Cmake to ver 3.7.x which causes me a lot of trouble - I just can't pass through cmake. The message I see in cmake is stating that it can't find fftw3 libs although the paths are defined properly - this is not happening in cmake 3.4.x (bilder downloaded on 2nd December 2016). Same machine+system (Ubuntu mate 16.04) used.
cmake_script.txt
cmake_run.txt
The text was updated successfully, but these errors were encountered: