I’ve written hundreds (thousands?) of GNU Makefiles over the past 30 years and never had a need to unconditionally run particular targets before all others. GNU Make utility is a rule-based language. I’d suggest what you’re attempting to do is enforce an imperative programming language model onto a rule-based programming language model, which you’re going to run into trouble trying to code in a different language model than the tool’s native model.
Can you provide what you mean by check the environment, and why you’d need to do that before anything else?
For example, in the past I’ve want to determine if and which particular command was installed, so I have near the top of my Makefile:
Using the := operator with $(shell …) is a way to run a command while GNU Make is initially parsing your Makefile. Normally, using := assignment operator is antithetical to a rule-based language, so you want to limit its use as much as possible, but unusual exceptions can exist.
I’m also unclear what you mean by “ensure variables are set”. What kind of variables?
The above snippet shows how you can check if a makefile variable is set when the Makefile is first parsed, if not, declare an error and exit. (The same approach works for environment variables too.)
Preparing a particular layout ahead of time is not the best approach. I’d suggest a given layout is nothing more than dependencies that should be declared as such.
Also, running specific targets or rules unconditionally can lead to trouble later as your Makefile grows up. You may eventually have additional targets that say provide information about the build’s state or run checks or tests. You wouldn’t want those targets necessarily to go off and build an entire tree of directories for you or take other unnecessary actions.
If you want to ensure certain directories are present, add those as dependencies for those targets with the | character. For example:
Even though I’ve been writing GNU Makefiles for decades, I still am learning new stuff constantly, so if someone has better, different ways, I’m certainly up for studying them.
Can you provide what you mean by check the environment, and why you’d need to do that before anything else?
One recent example is a makefile (in a subproject), w/ a dozen of targets to provision machines and run Ansible playbooks. Almost all the targets need at least a few variables to be set. Additionally, I needed any fresh invocation to clean the “build” directory before starting the work.
At first, I tried capturing those variables w/ a bunch of ifeqs, shells and defines. However, I wasn’t satisfied w/ the results for a couple of reasons:
Subjectively speaking, it didn’t turn out as nice and easy-to-read as I wanted it to.
I had to replicate my (admittedly simple) clean target as a shell command at the top of the file.
Then I tried capturing that in a target using bmakelib.error-if-blank and bmakelib.default-if-blank as below.
That’s why I thought there may be a better way of doing this which led me to the manual and then the method I describe in the post.
running specific targets or rules unconditionally can lead to trouble later as your Makefile grows up
That is true! My concern is that when the number of targets which don’t need that initialisation grows I may have to rethink my approach.
I’ll keep this thread posted of how this pans out as the makefile scales.
Even though I’ve been writing GNU Makefiles for decades, I still am learning new stuff constantly, so if someone has better, different ways, I’m certainly up for studying them.
Love the attitude! I’m on the same boat. I could have just kept doing what I already knew but I thought a bit of manual reading is going to be well worth it.
You may like an approach I came up with some time ago.
In my included file that’s common among my Makefiles:
<span style="color:#323232;"># Ensure the macro named is set to a non-empty value.
</span><span style="color:#323232;">varchk_call = $(if $($(1)),,$(error $(1) is not set from calling environment))
</span><span style="color:#323232;">
</span><span style="color:#323232;"># Ensure all the macros named in the list are set to a non-empty value.
</span><span style="color:#323232;">varchklist_call = $(foreach v,$(1),$(call varchk_call,$v))
</span>
At the top of a Makefile that I want to ensure certain variables are set before it runs:
To solve your DRY problem, you may not realize that you can generate target rules from built-in functions eval and foreach and a user-defined new-line macro. Think of it like a preprocessor step.
For example:
<span style="color:#323232;"># This defines a new-line macro. It must have two blank lines.
</span><span style="color:#323232;">define nl
</span><span style="color:#323232;">
</span><span style="color:#323232;">
</span><span style="color:#323232;">endef
</span><span style="color:#323232;">
</span><span style="color:#323232;"># Generate two rules for ansible playbooks:
</span><span style="color:#323232;">$(eval $(foreach v,1 2,
</span><span style="color:#323232;">.PHONY : ansible.run-playbook$v $(nl)
</span><span style="color:#323232;">
</span><span style="color:#323232;">ansible.run-playbook$v : ensure-variables cleanup-residue | $$(ansible.venv)$(nl)
</span><span style="color:#323232;">ansible.run-playbook$v :;
</span><span style="color:#323232;"> ... $(nl)
</span><span style="color:#323232;">))
</span>
I winged it a bit for you, but hopefully I got it right, or at least right enough you get what I’m doing with this technique.
TBH I use whatever build tool is the better fit for the job, be it Gradle, SBT or Rebar.
But for some (presumably subjective) reason, I like GNU Make quite a lot. And whenever I get the chance I use it - esp since it’s somehow ubiquitous nowadays w/ all the Linux containers/VMs everywhere and Homebrew on Mac machines.
I think I understand where RMS was coming from RE “recursive variables”. As I wrote in my blog:
Recursive variables are quite powerful as they introduce a pinch of imperative programming into the otherwise totally declarative nature of a Makefile.
They extend the capabilities of Make quite substantially. But like any other powerful tool, one needs to use them sparsely and responsibly or end up w/ a complex and hard to debug Makefile.
In my experience, most of the times I can avoid using recursive variables and instead lay out the rules and prerequisites in a way that does the same. However, occasionally, I’d have to resort to them and I’m thankful that RMS didn’t win and they exist in GNU Make today 😅 IMO purist solutions have a tendency to turn out impractical.
bahmanm.com
Top