Skip to content
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

Refactor to improve clarity of tribits_adjust_package_enables() and update users/maintainers guide some #615

Conversation

bartlettroscoe
Copy link
Member

This PR add some documentation to the users/maintainers guide and I noticed that the code in tribits_adjust_package_enables() could use some refactoring to improve its clarity.

See individual commits for details.

…maintainers guide

I had forgotten to do this when I wrote this code and this documentation.
This is an important function that defines how TriBITS treats internal and
external packages in a uniform way.

I also fixed some typos on the documentation.
This makes the logic in the code a little more understandable I think.  I was
looking over the code and I thought that this could be improved.  This will
get used in more code in future commits.  NOTE: This gets tested through
existing tests by usage in higher-level code (like the DependencyUnitTests
tests).

We will also need other functions like this to make the code more
self-documenting.

I also:

* Added a tailing impl comment to help try to explain something.

* Put the documented functions back in alphabetical order (moved
  tribits_process_enabled_standard_tpl()).
This makes the code more understandable.  NOTE: There is no specific unit test
for this but it is tested indirectly through higher-level code and tests (like
DependencyUnitTests tests).
You don't need a function tribits_package_is_not_explicitly_disabled() if you
have a function tribits_package_is_explicitly_disabled().  The code is just a
clear if you NOT the variable being returned from
tribits_package_is_explicitly_disabled()
This helps to make the code more clear.

NOTE: This is tested as part of higher-level code and tests
(e.g. DependencyUnitTests tests).
Turns out the function tribits_set_package_enable_based_on_project_enable()
was never called to default disable a package.

I updated the one call to this function to call
tribits_set_package_enable_based_on_project_enable_on() instead.
* Use tribits_package_is_explicitly_disabled()
* Use tribits_package_is_enabled_or_unset()
Copy link
Collaborator

@rabartlett1972 rabartlett1972 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the tests are strong enough and the changes are minimal enough that this does not need an outside review. (And it is not clear who is available to review TriBITS changes.)

@bartlettroscoe bartlettroscoe merged commit 7cfa35a into TriBITSPub:master Sep 1, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants