search

trilinos / Trilinos

Primary repository for the Trilinos Project
https://trilinos.org/
Other
1.22k stars 570 forks source link

Add automated tests for each package to check growth of library size #6032

Open bartlettroscoe opened 5 years ago

bartlettroscoe commented 5 years ago

CC: @trilinos/muelu, @jjellio, @tcfisher

When libraries in Trilinos grow too large, APPs can no longer link against them. Example of this and related issues include #3137, #1605, #4696, #3069, #4984. Rather than have this come as a surprise, it would be great if we could add automated testing to detect when libraries were getting too large and and warn us so that we can fix the problem before it was too late and important builds of Trilinos were broken for important APP customers (e.g. ATDM).

The idea first mentioned in https://github.com/trilinos/Trilinos/issues/3137#issuecomment-538063234 would be to extend TriBITS to optionally add a new test for each TriBITS package that would search for all of the pre-built libraries i that package and then check their size and compare against some max size (e.g. 4G minus some buffer size like 0.5G). If the size of any library was fund to be too big, the test would fail. Otherwise, test would just list out each of the libraries and their size when submitting to CDash.

bartlettroscoe commented 5 years ago

@trilinos/framework,

After some more thought, it might be better to setup hard size checks and test failures for library sizes in post-merge nightly builds (e.g. in the ATDM Trilinos builds) instead of in Trilinos PR builds. That way, we will be running the builds with the exact Trilinos configuration on the exact compilers and the exact configurations that our customers care about. We can set up a nightly summary email (using the cdash_analyze_and_report.py tool) to report to the Trilinos framework team on just this category of failing tests.

jjellio commented 4 years ago

@bartlettroscoe I guess I missed this in 2019.

I believe the techniques I have can enable pretty much everything you want. I've show Micheal Wolf, @kddevin, and Dena Vigil examples of how to visualize this stuff. The visualizer is broken, since I've added more fields, but fixing it is probably not too hard. I've posted tabular data to Trilinos CDOFA-119.

github-actions[bot] commented 3 years ago

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label. If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE. If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

bartlettroscoe commented 3 years ago

With the merge of PR #8638, I think we have the ability to do this now with Trilinos. It would not be hard at all to write tests to use build stats to error out when the size of any library or object file got too big.

github-actions[bot] commented 2 years ago

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label. If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE. If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

github-actions[bot] commented 1 year ago

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label. If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE. If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.