Prune export libraries and package lists #60
Conversation
This commit makes sure that the exported *_LIBRARIES variable only contains libraries from the current package, not all of its dependencies. The dependency management is done my CMake's target export files already. The same goes for the TPL variables.
Before, each INCLUDE() dependency was listed individually. This commit significantly shortens the export files.
This variable is intrinsic to CMake since 2.8.3.
We really only need the direct dependencies of the respective package.
|
Nico, Since I don't currently have any projects that use Config.cmake files and there is very little automated testing for them in TriBITS, I am reluctant to merge this branch without further testing against. In particular, we have to know if this works with Albany. You can access Albany at: |
|
I've been involved with Albany before and will look at it. First thing I can say by looking at https://github.com/gahansen/Albany/blob/master/CMakeLists.txt is that I wonder how this ever worked without setting |
|
Looks like fixing Albany won't be too easy, see, e.g., https://github.com/gahansen/Albany/issues/2. |
|
I managed to compile, link, and test Albany and Nosh successfully against this without related changes in the consumer code. Note that Albany's build system contained some other errors fixes by https://github.com/gahansen/Albany/pull/5. |
|
Nico, I just posted a new Issue #63 to extend TriBITS in a pretty significant way. I would like to discuss with you how the |
|
From http://public.kitware.com/pipermail/cmake/2015-April/060331.html:
|
|
I will review this further and see how this looks. If it looks good, I will merge and push. |
…BITS TriBITSPub#60) This trims down the generated <Package>Config.cmake files to only contain the direct libraries and include dirs for each SE package. This commit is a squash of several smaller commits shown below. 1) start cleaning up the export files 2 export files: INCLUDE() dependencies in FOREACH loop 3) export files: remove redundant definition of CMAKE_CURRENT_LIST_DIR This variable is intrinsic to CMake since 2.8.3. 4) don't use ALL dependencies in PACKAGE_LIST We really only need the direct dependencies of the respective package. 5) typo in variable name 6) fix for Makefile exports, adapt cmake export tests 7) fix unit test 8) fix unit test 125 9) fix unit test 127
|
I have done an initial review. I have a few questions about how this is supposed to work and there needs to be a few test cases added to make me feel comfortable merging in these changes (see the 'ToDo' list at the bottom of this comment). I am willing to help with the todos but I feel like I need to understand what is going on at this point (expecially given the expanded importance of the Let me know if when you might have time to discuss some of this some. Detailed Review: Reviewing the pull request ... First I checkout the branch and rebase it on top of origin/master: I then pushed that branch to my github repo: I then look at the files that are changed: The changes to the files: where only to change '/usr/bin/' to '/usr/bin/env'. I tested this on my machine and it seemed to work. The remaining changed files are: These files were changed in bunch of commits: These are not atomic commits so it would be good to squash these together before pushing. When I do that, I will make Nico the author so that he maintains credit (or takes the blame :-), whatever the case). Looking at the changes themselves with: I can see the effects of the change just from looking at the automated tests: It seems the export files are now only listing the direct SE package dependencies and only the libraries owned by that given SE package. We also see this change in the unit tests for the generated Config.cmake files: This is the generated list of libraries before the package 'RTOp' libraries are defined. The unit test for the generated export makefiles is unchanged. The unit tests for after the package 'RTOp' libraries are defined shows the diff: The list of TPLs is empty because the package RTOp has no direct TPL dependencies. The rest of the unit tests are untouched, including the tests that check the export makefiles. However, I feel like these unit tests are now somewhat lacking because they don't show TPL dependencies anymore. Looking at the changes in the TriBITS code itself, summarized as: the changes look very reasonable given the goal of removing implicit upstream dependencies from the Config.cmake files. It looks like there might be a minor (negative) performance impact for this change. However, if you only generate Now to test this with CASL VERA building the I got the branch with: I then configured, built, and tested with: That built and returned all passing tests: I then squashed this down to two commits (with The commit bb71ab0 "/bin/env -> /usr/bin/env" has nothing to do with the export makefiles so I will cherry-pick that commit and just push it right away ... After pushing that commit, and rebasing on top of origin/master, the remaing commit is just: I pushed this to the updated branch: Looking at the generated but we see the includes for all of the upstream packages (including the implicit upstream package Why would you include the the file Also, from looking at the updated generated ToDo:
|
|
Nico, The page cmake-packages(7) suggests that the
|
I assume one of the two is supposed to include |
|
Nico, Of course you are right. That was a mistake. I updated the comment to say " the So, do you agree with this? That is what the Kitware documentation says to do and that makes good sense I think. You should only have to include |
Yup. The target include line also appears in every config export in the last line. |
|
@bartlettroscoe, I'd like to bring this back to attention. |
|
Given that all of this export stuff is so poorly tested right now I am hesitant to make such a change. For example, how does this impact the generated Makefile.export. files? But if you are willing to respond to an problems that people encounter, then I will go ahead and rebase and merge this branch. In any case, all of this will be revisited as part of the major refactoring #63. That is why I did not look into this too much. But that refactoring has been delayed for a long time. |
|
I believe this PR is somewhat orthogonal to #63. Here, we try to keep to avoid the blowing up of the link line as it currently happens, #63 merges TPLs and packages (which I also strongly support).
I agree. So let's get some tests in order. :) What would think is a reasonable approach? |
TriBITS nor any of my projects uses these TriBITS-generated So you can see there is some existing automated testing for the TriBITS-generated |
bartlettroscoe
force-pushed
the
master
branch
from
ebf7118 to
3605bfe
Compare
|
The only conflicts are in the tests file so this should be easy to resolve. |
This pull request cleans up the cluttered export variables.
In
TribitsWriteClientExportFiles.cmake, great lengths are gone to capture the entire dependency tree of every single package. None of this is actually necessary: Much of the dependency handling can be done by CMake itself. There is much room for cleaning up the export functionality, and this pull request makes a start by creating leaner export files.Fixes bug #32.