Thanks for the pointer! Very interesting. I actually may end up doing a prototype and see how far I can get.

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 ifeqs, shells and defines. However, I wasn’t satisfied w/ the results for a couple of reasons:

1. Subjectively speaking, it didn’t turn out as nice and easy-to-read as I wanted it to.
2. 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.

That’s a great starting point - and a good read anyways!

Thanks 🙏

Agree w/ you re trust.

Thanks. At least I’ve got a few clues to look for when auditing such code.

Update

sh.itjust.works in now added to lemmy-meter 🥳 Thanks all.

RE Go: Others have already mentioned the right way, thought I’d personally prefer ~/opt/go over what was suggested.

RE Perl: To instruct Perl to install to another directory, for example to ~/opt/perl5, put the following lines somewhere in your bash init files.

export PERL5LIB="$HOME/opt/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"
export PERL_LOCAL_LIB_ROOT="$HOME/opt/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"
export PERL_MB_OPT="--install_base \"$HOME/opt/perl5\""
export PERL_MM_OPT="INSTALL_BASE=$HOME/opt/perl5"
export PATH="$HOME/opt/perl5/bin${PATH:+:${PATH}}"

Though you need to re-install the Perl packages you had previously installed.

That was my case until I discovered that GNU tar has got a pretty decent online manual - it’s way better written than the manpage. I rarely forget the options nowadays even though I dont’ use tar that frequently.

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.

Uh, I’m not sure I understand what you mean.

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 just quote my comment on a similar post earlier 😅

A bit too long for my brain but nonetheless it is written in plain English, conveys the message very clearly and is definitely a very good read on the topic. Thanks for sharing.

That single line of Lisp is probably (defmacro generate-compiler (...) ...) which GCC folks call every time they decide to implement a new compiler 😆

Now that I know which endpoints I’m interested in and which arguments I need to pass, exporting them to Prometheus is my next step. Though I wasn’t sure where to begin w/ - I was thinking about writing the HTTP requests in Java or Python and export the results from there.

Blackbox exporter is definitely easier and cleaner. Thanks for the tip 💯

I agree w/ you RE posts looking horrible 👍

Though I’d say for one-liners like this, it’s mostly OK. It gets really messy when folks post more complex posts and mention and tag a bunch of times.

I’m afraid I can’t be of any help 😕

Any error logs? Try launching things from the terminal and note down any messages that are printed there.

That’s a good question 💯 In my case too, it took me some time (read years 😂) to figure out what I’m comfortable w/.

I can think of 3 major ways that you can navigate the filesystem while being able to drop to a shell when you need it:

• If you’re familiar w/ Emacs, you can either:
  • Use dired and tramp on your machine to access/navigate the target machine.
  • Install Emacs (emacs-nox) on the target machine, SSH and then run emacs-nox and voila! No need for tramp in this scenario.
• Use Midnight Commander (mc) which offers a TUI pretty much like Norton Commander (nc) from the days of yore.
• Get used to the semi-standard structure of the file system and just use plain Bash (cd, pushd & popd) to move around. That is
  • Understand what usually goes into common directories (like /usr/share or /opt) and try to follow the same pattern when rolling your own software installations.
  • Learn how to use your distro’s package manager to query packages and find out where things, like configurations and docs, are stored. Something as simple as rpm -q --list is what you usually need.

HTH