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

Use Make conditionals #1168

Merged
merged 8 commits into from
Jan 15, 2025
Merged

Use Make conditionals #1168

merged 8 commits into from
Jan 15, 2025

Conversation

gouttegd
Copy link
Contributor

@gouttegd gouttegd commented Jan 13, 2025

This PR updates the standard Makefile template to replace, wherever possible, shell conditionals by Make conditionals.

That is, rules like the following:

my_target: my_dependencies
    if [ $(MY_VAR) = true ]; then <code to generate my_target> ; fi

my_other_target: my_other_dependencies
    if [ $(MY_VAR) = true ]; then <code to generate my_other_target> ; fi

is replaced by

ifeq ($(MY_VAR),true)
my_target: my_dependencies
    <code to generate my_target>

my_other_target: my_other_dependencies
    <code to generate my_other_target>
endif

closes #912

Instead of using shell conditionals (`if [ $(IMP) = true ]; then ... ;
fi`) in all targets of the imports section, bracket the entire section
in a single Make conditional.
Some pre-existing Make conditionals were using the following form:

  ifeq ($(strip $(VARIABLE),true))

This is because some VARIABLES were declared with a comment on the same
line, as in

  VARIABLE = true # some comment

The presence of the comment causes Make to treat the whitespaces on the
line as significant, meaning that VARIABLE in the example above has the
value " true ", instead of "true". Using the `strip` function in the
condition allowed to test against the intended value of the variable,
rather than the value effectively set.

But it is actually better to fix the declaration of the variable (moving
the comment to the line above), once and for all, than to strip
whitespaces whenever the variable is tested. This has been done for all
affected variables, so the calls to `strip` are no longer necessary.
Apply to targets of the components pipeline the same principle as for
mirrors and imports: bracket the entire section within a single Make
conditional on the COMP variable.

Also, use a Make conditional on the MIR variable to avoid re-generating
a component that is downloaded from a remote source when MIR is false.
The general rule is that when MIR is set to false, nothing should ever
be fetched from a remote source -- pipelines should only use locally
available resources.

So if a mapping set is defined as having a remote source, we bracket the
rule that downloads that set in a Make conditional on MIR.
Apply to the DOSDP pipeline targets the same principle as for the
imports, mirrors, and components pipelines: bracket the entire section
in a Make conditional on the PAT variable.
It shouldn't be necessary to have a rule that does nothing but display a
message that says that nothing is being done.
@gouttegd gouttegd self-assigned this Jan 13, 2025
I missed the fact that this rule is supposed to behave differently
depending on whether the pattern pipeline is enabled or not. So in this
particular instance we need two rules: one in the block where PAT is
true, and one in the alternative block.
@gouttegd gouttegd requested a review from matentzn January 13, 2025 21:37
Copy link
Contributor

@matentzn matentzn left a comment

Choose a reason for hiding this comment

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

Ohhh thanks that will be soo much help for me.

Just a few minor comments, reassign me to approve.

template/src/ontology/Makefile.jinja2 Outdated Show resolved Hide resolved
template/src/ontology/Makefile.jinja2 Show resolved Hide resolved
template/src/ontology/Makefile.jinja2 Show resolved Hide resolved
template/src/ontology/Makefile.jinja2 Show resolved Hide resolved
Declare all the variables that control whether workflows are enabled
(MIR, IMP/IMP_LARGE, COMP, and PAT) in a single block near the beginning
of the Makefile.

This both ensures that all such variables are always declared before
they are used, and makes it easier for users to find them and understand
what they are for.
@gouttegd gouttegd requested a review from matentzn January 14, 2025 14:26
Copy link
Contributor

@matentzn matentzn left a comment

Choose a reason for hiding this comment

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

Looks great, didnt do testing, just code review. THANKS!

@gouttegd gouttegd merged commit aceb1b0 into master Jan 15, 2025
1 check passed
@gouttegd gouttegd deleted the use-make-conditionals branch January 15, 2025 10:11
@gouttegd
Copy link
Contributor Author

gouttegd commented Jan 15, 2025

Regarding the need for testing: I’d say that it can be done as part of the normal testing we do prior to a major release (as outlined here). During development, it’s OK to rely mostly on the CI-based testing + code reviews for most PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Schnapsidee: Favour Make conditionals over shell conditionals
2 participants