easybuilders / easybuild-easyblocks

Collection of easyblocks that implement support for building and installing software with EasyBuild.
https://easybuild.io
GNU General Public License v2.0
102 stars 278 forks source link

forced reinstallation of ROOT fails with missing vdt/vdtMath.h #2023

Open boegel opened 4 years ago

boegel commented 4 years ago

Forced reinstalled of (for example) ROOT-6.14.06-foss-2018b-Python-2.7.15.eb is failing during make install with:

In file included from input_line_12:7:
/tmp/kehoste/easybuild/build/ROOT/6.14.06/foss-2018b-Python-2.7.15/easybuild_obj/include/ROOT/RVec.hxx:36:10: fatal error: 'vdt/vdtMath.h' file not found                                                                                                                     
#include <vdt/vdtMath.h>
         ^~~~~~~~~~~~~~~                                                                                                               
Error: /tmp/kehoste/easybuild/build/ROOT/6.14.06/foss-2018b-Python-2.7.15/easybuild_obj/bin/rootcling: compilation failure (/tmp/kehoste/easybuild/build/ROOT/6.14.06/foss-2018b-Python-2.7.15/easybuild_obj/lib/libROOTVecOpsc24bc4f618_dictUmbrella.h)                      
make[2]: *** [math/vecops/G__ROOTVecOps.cxx] Error 1                                                                                   
make[2]: Leaving directory `/tmp/kehoste/easybuild/build/ROOT/6.14.06/foss-2018b-Python-2.7.15/easybuild_obj'                          
make[1]: *** [math/vecops/CMakeFiles/G__ROOTVecOps.dir/all] Error 2                                                                    
make[1]: Leaving directory `/tmp/kehoste/easybuild/build/ROOT/6.14.06/foss-2018b-Python-2.7.15/easybuild_obj'                          
make: *** [all] Error 2

This occurs because vdt/vdtMath.h was found in the existing ROOT installation directory at configure time, but since the installation directory is removed right before make install, the file is no longer there when make install tries to access it during the installation step.

ocaisa commented 3 years ago

I've also seen this behaviour for another CMakeMake package that installs a number of dependent CMake projects. I think it is picking up the CMake files of the old installations in the installation directory and deciding the requirements don't need to be built, but then the installation fails when the installation directory is blown away and these no longer exist. For the package I am looking at I think the relevant LoC is https://github.com/Goddard-Fortran-Ecosystem/pFUnit/blob/main/cmake/build_submodule.cmake#L10