search

TriBITSPub / TriBITS

TriBITS: Tribal Build, Integrate, and Test System,
http://tribits.org
Other
36 stars 46 forks source link

Parent <Package>Config.cmake files are empty in some cases #231

Open bartlettroscoe opened 7 years ago

bartlettroscoe commented 7 years ago

It appears that there may be a defect in TriBITS where a parent package's <Package>Config.cmake file my not list the dependencies of its subpackages, even when those subpackages are enabled. I think noticed this when I was working on the SPARC prototype build system for TriBITS when trying to read in the SEACASConfig.cmake file (and it was empty) and it looks like the ShyLU developers may have hit this judging from the commit trilinos/Trilinos@ede8fe1a3e82c9437ca42c0ef55b31b98ce44779:

commit ede8fe1a3e82c9437ca42c0ef55b31b98ce44779
Author: Siva Rajamanickam <srajama@sandia.gov>
Date:   Sun Oct 15 20:40:10 2017 -0600

     ShyLU/ShyLU_DD
       Added a new empty subpackage common as ST so that TriBITS
       generates the right cmake files. When all the subpackages were optional
       they were not generated even  when the package was explicitly enabled.
       Also fixed a minor thing in CMakelists.txt of the core.

M       packages/shylu/shylu_dd/cmake/Dependencies.cmake
A       packages/shylu/shylu_dd/common/CMakeLists.txt
A       packages/shylu/shylu_dd/common/cmake/Dependencies.cmake
A       packages/shylu/shylu_dd/common/cmake/ShyLU_DDCommon_config.h.in
A       packages/shylu/shylu_dd/common/src/CMakeLists.txt
A       packages/shylu/shylu_dd/common/src/dummy.cpp
M       packages/shylu/shylu_dd/core/src/CMakeLists.txt
bartlettroscoe commented 7 years ago

This needs to be looked into soon due to the increased dependence on these <Package>Config.cmake files with the work we are doing with ATDM.

srajama1 commented 7 years ago

It appears I didn't quite fix it. Making Common sub package ST doesn't fix the problem as tests could be turned off. May be making it REQUIRED will help ?

bartlettroscoe commented 7 years ago

It appears I didn't quite fix it. Making Common sub package ST doesn't fix the problem as tests could be turned off. May be making it REQUIRED will help ?

Note sure at this point. Will need to dig in and investigate what is happening with this. I will need to look at the <Package>Config.cmake files being produced by Trilinos for packages that have subpackages and see if I can see a pattern. I will need to do that before I can figure out how to add an automated test case to reproduce the problem so that I can fix this.

How urgent is this? For the case with SPARC and SEACAS, I just directly including the SEACAS subpackage's <Package>Config.cmake files that SPARC was actually using and that worked just fine. (In fact, you might argue that users should directly point to the subpackages they are using to better manage their dependencies.)