Open jrper opened 8 years ago
Had a quick look at that branch, and it looks great! Would be very interested to have a more detailed, offline discussion about how far you got.
Thanks from me also - currently completely tied up with learning the intricacies of Jenkins plus docker but very interested to discuss / look at this more when time permits.
I am terribly late to the party here, but is there any chance for this Fluidity CMake build to get finalised? The reason why I am asking is that CMake has deprecated the command-line argument --find-package
(e.g. here and here) which is used in Fluidity's configure
to retrieve some information about VTK. In particular, configure
fails with the newer VTK 9:
configure: Checking for VTK automagic.
CMake Error at /apps/cmake/3.18.2/share/cmake-3.18/Modules/FindThreads.cmake:62 (message):
FindThreads only works if either C or CXX language is enabled
Call Stack (most recent call first):
/g/data/xd2/modules/vtk/9.1.0/lib64/cmake/vtk-9.1/VTK-vtk-module-find-packages.cmake:115 (find_package)
/g/data/xd2/modules/vtk/9.1.0/lib64/cmake/vtk-9.1/vtk-config.cmake:150 (include)
/apps/cmake/3.18.2/share/cmake-3.18/Modules/CMakeFindPackageMode.cmake:183 (find_package)
There are probably workarounds to replace the erroring commands (associated source code called by --find-package
here)
VTK_FLAGS=`cmake --find-package -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=COMPILE`
VTK_LIBS=`cmake --find-package -DNAME=VTK -DCOMPILER_ID=gcc -DLANGUAGE=Fortran -DMODE=LINK`
using, for example, the approaches detailed here, here and here, but I have not had success with them. Potentially something along the lines of
cmake_minimum_required(VERSION 3.16)
project(VTK_Info)
find_package(VTK
REQUIRED)
message("${VTK_VERSION}")
message("${VTK_MAJOR_VERSION}")
message("${VTK_MINOR_VERSION}")
message("${VTK_BUILD_VERSION}")
message("${VTK_AVAILABLE_COMPONENTS}")
message("${VTK_PREFIX_PATH}")
message("${VTK_LEGACY_REMOVE}")
message("${VTK_HAS_VTKm}")
message("${VTK_PYTHON_VERSION}")
message("${VTK_WRAP_PYTHON}")
message("${VTK_PYTHONPATH}")
message("${VTK_LIBRARIES}")
message("${VTK_AUTOINIT_INCLUDE}")
message("${VTK_QT_VERSION}")
message("${VTK_QML_DIR}")
message("${VTK_ENABLE_VR_COLLABORATION}")
message("${VTK_SMP_BACKENDS}")
foreach(lib_name ${VTK_LIBRARIES})
get_target_property(lib_file ${lib_name} LOCATION)
get_target_property(include_dir ${lib_name} INTERFACE_INCLUDE_DIRECTORIES)
message("${lib_file}")
message("${include_dir}")
endforeach()
could contain valuable information for Fluidity's configure
, but my knowledge here is limited. Any input greatly appreciated.
Impressive thread necromancy there, @Patol75 :-)
I'd also be very keen to revive this one as the VTK/CMake thing has been biting me frequently over the past couple of years. I've generally given up on anything automated and just hacked configure / Makefiles to get the info in.
Unfortunately at the moment IC ESE has reassigned my job to cover for missing staff in the department and I have no time to do any Fluidity work until things settle down :-(
In a previous issue ( #113 ) @ggorman suggested migrating fluidity to use CMake as its build system would make some of our support issues (particularly VTK) easier. Over the long weekend I've been experimenting with getting a working build together (see the branch https://github.com/FluidityProject/fluidity/tree/cmake_build). It's not finished yet, and brought up some other issues I'll be questioning shortly, but to summarise my findings so far:
however, as @stephankramer said, debugging is annoying and it's unclear which of multiple routes is the best way to pass a given flag to a given compiler.
I'm assuming this will be a won't fix, but I thought I'd open this to further discussion, particularly in the case that there's interest in having an experimental or unsupported CMake build scheme available for people on weird systems.