![User's banner](/_next/image?url=https%3A%2F%2Flemm.ee%2Fapi%2Fv3%2Fimage_proxy%3Furl%3Dhttps%253A%252F%252Flemmy.ml%252Fpictrs%252Fimage%252F338f99f4-4803-43ea-8f9c-f371a5effbc5.jpeg&w=2048&q=75)
![Avatar](/_next/image?url=https%3A%2F%2Flemm.ee%2Fapi%2Fv3%2Fimage_proxy%3Furl%3Dhttps%253A%252F%252Flemmy.ml%252Fpictrs%252Fimage%252F6bc83bcc-037e-4b71-b71c-f705f2df0be9.png&w=3840&q=75)
![Avatar](/_next/image?url=%2Flemmy-icon-96x96.webp&w=3840&q=75)
bahmanm
Husband, father, kabab lover, history buff, chess fan and software engineer. Believes creating software must resemble art: intuitive creation and joyful discovery.
๐ linktr.ee/bahmanm
Views are my own.
Good question!
IMO a good way to help a FOSS maintainer is to actually use the software (esp pre-release) and report bugs instead of working around them. Besides helping the project quality, Iโd find it very heart-warming to receive feedback from users; it means people out there are actually not only using the software but care enough for it to take their time, report bugs and test patches.
I usually capture all my development-time โautomationโ in Make and Ansible files. I also use makefiles to provide a consisent set of commands for the CI/CD pipelines to work w/ in case different projects use different build tools. That way CI/CD only needs to know about make build
, make test
, make package
, โฆ instead of Gradle/Maven/โฆ specific commands.
Most of the times, the makefiles are quite simple and donโt need much comments. However, there are times thatโs not the case and hence the need to write a line of comment on particular targets and variables.
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 ifeq
s, shell
s and define
s. 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.
##############
.PHONY : ensure-variables
ensure-variables : bmakelib.error-if-blank( VAR1 VAR2 )
ensure-variables : bmakelib.default-if-blank( VAR3,foo )
##############
.PHONY : ansible.run-playbook1
ansible.run-playbook1 : ensure-variables cleanup-residue | $(ansible.venv)
ansible.run-playbook1 :
...
##############
.PHONY : ansible.run-playbook2
ansible.run-playbook2 : ensure-variables cleanup-residue | $(ansible.venv)
ansible.run-playbook2 :
...
##############
But this was not DRY as I had to repeat myself.
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.