-
Notifications
You must be signed in to change notification settings - Fork 45
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
Fix installed <tplName>Config.cmake files to not point into build tree #500
Comments
NOTE: It would be good to fix this in a way that allows for relocatable installs. So instead of creating separate |
This one bit GEMMA as well. Oddly, not on all platforms. I'm going to wait to get into any depth as to why it only bit us on the ASCICGPU platforms but not the ASCIC (non GPU) platforms to see if your fix gets rid of the problem. |
@glhenni, if the build directory is visible and accessible from the configure process for the downstream APP, it will work. For SPARC, the Trilinos builds were done on one machine under /scratch/ different from where the SPARC configures were done and, therefore, none of the SPARC configurations could find them and they all broke. I should have a fix in for this by the end of the day hopefully (after I get a TriBITS test to demonstrate the problem). |
…d <tplName>Config.cmake files (TriBITSPub#500) The updated some tests to copy in the source dir, build and install in different subdirs, and delete the soruce and build dir. Then the downstream TribitsExampleApp2 tests configure and build against the install dirs where no src or build dir exists. And with this, we see the defect in the installed <tplName>Config.cmake showing them pointing into the build dir for find_dependency() calls called out in (TriBITSPub#500). NOTE: The 'find_package' tests did not show any errors because they ignore upstream TPL dependencies. They just set <externalPkg>_DIR to what was found by the call to find_package(<externalPkg>) in the FindTPL<tplName>.cmake module. The generated <tplName>Config.cmake file sets <externalPkg>_DIR to that same dir and then calls find_dependency(<externalPkg>). The assumption is that <externalPkg> is found outside of the build dir and will be valid for installs as well.
…ub#500) Now, this sets <upstreamTplName>_DIR in Tribits wrapper files to set <upstreamTplName>_DIR to "${CMAKE_CURRENT_LIST_DIR}/../<upstreamTplName>}. This will work for the the build tree and the install tree. It also makes the install relocatable, w.r.t. these files. Note that we did not change <externalPkg>_DIR in the <tplName>Config.cmake file generated using the function tribits_extpkg_create_package_config_file_with_imported_targets(). That is because those are for external packages that should not be in the build tree but should instead be in the install tree. To make those <tplName>Config.cmake files relocatable would be more work (where we would need to compute relative paths and use those instead when asked).
…d <tplName>Config.cmake files (TriBITSPub#500) The updated some tests to copy in the source dir, build and install in different subdirs, and delete the soruce and build dir. Then the downstream TribitsExampleApp2 tests configure and build against the install dirs where no src or build dir exists. And with this, we see the defect in the installed <tplName>Config.cmake showing them pointing into the build dir for find_dependency() calls called out in (TriBITSPub#500). NOTE: The 'find_package' tests did not show any errors because they ignore upstream TPL dependencies. They just set <externalPkg>_DIR to what was found by the call to find_package(<externalPkg>) in the FindTPL<tplName>.cmake module. The generated <tplName>Config.cmake file sets <externalPkg>_DIR to that same dir and then calls find_dependency(<externalPkg>). The assumption is that <externalPkg> is found outside of the build dir and will be valid for installs as well. NOTE: I also moved ALWAYS_FAIL_ON_NONZERO_RETURN to the bottom of TEST_<IDX> blocks to make them more noticable (and that is typically where I put them).
…ub#500) Now, this sets <upstreamTplName>_DIR in Tribits wrapper files to set <upstreamTplName>_DIR to "${CMAKE_CURRENT_LIST_DIR}/../<upstreamTplName>}. This will work for the the build tree and the install tree. It also makes the install relocatable, w.r.t. these files. Note that we did not change <externalPkg>_DIR in the <tplName>Config.cmake file generated using the function tribits_extpkg_create_package_config_file_with_imported_targets(). That is because those are for external packages that should not be in the build tree but should instead be in the install tree. To make those <tplName>Config.cmake files relocatable would be more work (where we would need to compute relative paths and use those instead when asked).
FYI: The updated tests exposing the defect and the fix are in PR #501. |
…l-tree Fix <tplName>Config.cmake files to not point into build dir (#500)
…all-tree (trilinos#10774) Addresses TriBITSPub/TriBITS#500 which is part of trilinos#10774.
…nual-updates (#10774) Addresses TriBITSPub/TriBITS#500
This was confirmed in GEMMA testing as documented in trilinos/Trilinos#10784 (comment) and we see this issue fixed in the SPARC Trilinos Integration builds starting 2022-07-22. |
As described in trilinos/Trilinos#10774 (comment), the current TriBITS-installed
<tplName>Config.cmake
files are setting<upstreamTplName>_DIR
to point into the build tree instead of the install tree. This is breaking all of the SPARC Trilinos Integration builds starting SPARC testing day 2022-07-19.Tasks
The text was updated successfully, but these errors were encountered: