Husband, father, kabab lover, history buff, chess fan and software engineer. Believes creating software must resemble art: intuitive creation and joyful discovery.
Views are my own.
Thanks. Bookmarked the site. Also noted RE age.
Thanks. I’d go the online route if my kid was a few years older but given the age, I believe in-person lessons are the best for now.
Thanks. Bookmarked.
UPDATE: lemmy.ml is now on lemmy-meter 🥳
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.
“Announcment”
It used to be quite common on mailing lists to categorise/tag threads by using subject prefixes such as “ANN”, “HELP”, “BUG” and “RESOLVED”.
It’s just an old habit but I feel my messages/posts lack some clarity if I don’t do it 😅
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:
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.
Oh, neat!
On another note: ~2 mins looks like rather a “long” window of maintenance/disruption for what Cloudflare is 🙈
I’m not an 1.e4 or Sicilian player but this smells like wild tactical variations early in the game.
Done ✅
Thanks for your interest 🙏
Please do drop a line in either !lemmy_meter@lemmy.ml or #lemmy-meter:matrix.org if you’ve got feedback/ideas for a better lemmy-meter. I’d love to hear them!
Oh and feel free to link back to lemmy-meter from Blåhaj if you’d like to, in case you’d prefer the community to know about it.
lemmy.one is added to lemmy-meter 🥳
Please do reach out if you’ve got feedback/suggestions/ideas for a better lemmy-meter 🙏
You can always find me and other interested folks in
Oh, sorry to hear that 😕
I think I’ll just go ahead and add you folks to lemmy-meter for now. In case you want to be removed, it should take only a few minutes.
I’ll keep this thread posted once things are done.
It’s on 🥳
If you’ve got questions/feedback/ideas please drop a line in either
Thanks for showing interest 🙏
sh.itjust.works in now added to lemmy-meter 🥳 Thanks all.
I didn’t like the capitalised names so configured xdg to use all lowercase letters. That’s why ~/opt
fits in pretty nicely.
You’ve got a point re ~/.local/opt
but I personally like the idea of having the important bits right in my home dir. Here’s my layout (which I’m quite used to now after all these years):
$ ls ~
bin
desktop
doc
downloads
mnt
music
opt
pictures
public
src
templates
tmp
videos
workspace
where
bin
is just a bunch of symlinks to frequently used apps from opt
src
is where i keep clones of repos (but I don’t do work in src
)workspace
is a where I do my work on git worktrees (based off src
)
Thanks for the pointer! Very interesting. I actually may end up doing a prototype and see how far I can get.