Fix find_package(<Package>) calls from TriBITS-generated <Package>Config.cmake files from different dirs (#299)

[bartlettroscoe]

It was reported that the new TriBITS-generated <Pacakge>Config.cmake files don't work correctly when calling find_package(<Package>) from different directories for different packages that have a dependency relationship. This was reported from a SEACAS project customer that is trying to call find_package() from two different directories for two different SEACAS subpackages from that have a dependency. An small reproducer was provided:

• cmake-seacas-error.tar.txt

This has the directory structure:

 ~/tree.py -cf .
  cmake-seacas-error/
  +-CMakeLists.txt
  +-a/
  | +-CMakeLists.txt
  +-b/
  | +-CMakeLists.txt
  | +-b.cpp

The file cmake-seacas-error/a/CMakeLists.txt has:

find_package(SEACASExodus REQUIRED HINTS /projects/seacas/linux_rhel7/current)

while the file cmake-seacas-error/b/CMakeLists.txt has:

find_package(SEACASNemesis REQUIRED HINTS /projects/seacas/linux_rhel7/current)

It is reported that the second call to find_package(SEACASNemesis ...) results in the error:

08:13:39    Found package configuration file:
08:13:39  
08:13:39      /projects/seacas/linux_rhel7/current/lib/cmake/SEACASNemesis/SEACASNemesisConfig.cmake
08:13:39  
08:13:39    but it set SEACASNemesis_FOUND to FALSE so package "SEACASNemesis" is
08:13:39    considered to be NOT FOUND.  Reason given by package:
08:13:39  
08:13:39    The following imported targets are referenced, but are missing:
08:13:39    SEACASExodus::all_libs

This suggests a problem with how the new TriBITS-generated files are written using include_guard(GLOBAL).

[bartlettroscoe]

I was able to reproduce the error on 'hpws055' using the slightly simplified project:

$ ~/tree.py -cf cmake-seacas-error2
  cmake-seacas-error2/
  +-CMakeLists.txt
  +-a/
  | +-CMakeLists.txt
  +-b/
  | +-CMakeLists.txt

with the project:

cmake-seacas-error2.tar.txt

where the files are:

$ cat cmake-seacas-error2/CMakeLists.txt 
cmake_minimum_required(VERSION 3.12)

project(test NONE)

add_subdirectory(a)
add_subdirectory(b)

$ cat cmake-seacas-error2/a/CMakeLists.txt 
find_package(SEACASExodus REQUIRED HINTS /projects/seacas/linux_rhel7/current)

$ cat cmake-seacas-error2/b/CMakeLists.txt 
find_package(SEACASNemesis REQUIRED HINTS /projects/seacas/linux_rhel7/current)

Configuring this project gives:

$ cmake ../cmake-seacas-error2
CMake Error at b/CMakeLists.txt:1 (find_package):
  Found package configuration file:

    /projects/seacas/linux_rhel7/current/lib/cmake/SEACASNemesis/SEACASNemesisConfig.cmake

  but it set SEACASNemesis_FOUND to FALSE so package "SEACASNemesis" is
  considered to be NOT FOUND.  Reason given by package:

  The following imported targets are referenced, but are missing:
  SEACASExodus::all_libs



-- Configuring incomplete, errors occurred!
See also "/ascldap/users/rabartl/junk/cmake-seacas-error/build/CMakeFiles/CMakeOutput.log".

[bartlettroscoe]

So the situation is that SEACASNemeis has a direct dependency on SEACASExodus as shown by:

$ cd seacas/

$ find packages/ -name Dependencies.cmake -exec grep -nH "SEACASExodus" {} \; | grep nemesis
packages/seacas/libraries/nemesis/cmake/Dependencies.cmake:2:  LIB_REQUIRED_PACKAGES SEACASExodus

So I should be able to create a test in TriBITS that has a similar relationship and show this occuring.

[clintonstimpson]

Thanks Ross for submitting this for me. We have a project currently not building because of this.
I guess one workaround would be for us to move both find_package() calls up to the parent directory.

[bartlettroscoe]

We have a project currently not building because of this.

@clintonstimpson, I will comment back here with status once I know more. Hopefully we can fix this quickly without having to modify your CMake project. (The thing working against us is that the standard way of writing <Package>Config.cmake files does not scale and makes find_package(Trilinos ...) take over 20 minutes to run.)

[bartlettroscoe]

@gsjaardema, can you please update the TriBITS snapshot in the SEACAS repo? I think the PR #506 just merged will fix this bug reported by @clintonstimpson and documented above.

[bartlettroscoe]

FYI: @clintonstimpson confirmed in a separate email that after SEACAS updated its snapshot of TriBITS 'master', his use case now works.

Closing this as complete.