Je comprends l’exaspération devant la dette technique de tout projet. Malheureusement, un projet commence par créer de la dette pour valider un concept. L’important est d’avoir les moyens de remanier le projet régulièrement, le premier étant les tests fonctionnels comme le dit l’article.

Je privilégie même les tests de bout en bout (end to end). Par définition, les tests unitaires doivent être remaniés avec le code qu’ils testent.

Qu’est-ce qu’un Shell ? Une interface utilisateur pour interagir avec le système d’exploitation. J’ai l’impression que Nushell c’est une interface pour interagir avec un système d’information. En plus, c’est pas encore abouti.

Optimisé pour un serveur. Pas pour un usage desktop et encore moins laptop.

S’il n’y avait que cela… Beaucoup d’utilisation de cat inutiles et des commandes hasardeuses, exemples :

coeurs=`cat /proc/cpuinfo | grep -i "^processor" | wc -l`

au lieu de :

coeurs=$(grep -c ^model /proc/cpuinfo)

addrip=`hostname -I | cut -d " " -f2`

qui récupère arbitrairement uniquement la seconde adresses IP de la sortie de commande, résultat un utilisateur se pliant de ne voir que son IPv6 :-D

Ce n’est pas quick-tutoriel mais quick-old-and-dirty-tuitoriel :D

Et sinon en graphique il y a baobab un outil bien pratique

Abonnez-vous bien sûr à la chaîne merci.

Vous n’avez pas répondu à mon commentaire précédent. Plusieurs choses me font sourciller. Le Shell c’est trop compliqué pour ne pas en rajouter. Voir Affichage des variables.

memfree=`cat /proc/meminfo | grep MemFree | awk {'print $2'}`

C’est pas bien !

memFree=$(awk '/MemFree/ {print $2}' /proc/meminfo)

Intéressant. Le passage sur les paradigmes déclaratif et procédural dans le paragraphe « Construire des usines à gaz » m’interroge fortement, ceci dans plusieurs domaines portant sur divers aspects. Qu’entendez-vous par « infrastructure » ? Brièvement, qu’est-ce que cela représente ?

Abonnez-vous pour ne rien rater

Beaucoup d’erreurs dans son fichier Docker Compose. Bon, du coup c’est didactique parce qu’il faut corriger.

Je ne peux plus éditer le message contenant le Makefile mais il contient des erreurs. Par exemple, les chemins dans les variables $(objs_tex) et $(objs_svg) sont spécifiés par rapport aux préfixes src/ et svg/ comme src/foo.pdf au lieu de foo.pdf ou bien $(BUILD_DIR)/foo.pdf.

Édition :

--- ./a/Makefile	2023-09-09 10:55:10.779735632 +0200
+++ ./b/Makefile	2023-09-09 10:50:40.963075540 +0200
@@ -16,8 +16,14 @@
 srcs_svg := $(wildcard svg/*.svg) 
 srcs_bitmap := $(wildcard bitmap/*.*)
 srcs := $(srcs_tex) $(srcs_svg) $(src_bitmap)
-objs_tex := $(srcs_tex:.tex=.pdf)
-objs_svg := $(srcs_svg:.svg=.pdf)
+ifdef $(BUILD_DIR)
+   objs_tex := $(addprefix $(BUILD_DIR)/, $(notdir $(srcs_tex:.tex=.pdf)))
+   objs_svg := $(addprefix $(BUILD_DIR)/, $(notdir $(srcs_svg:.svg=.pdf)))
+else
+   objs_tex := $(notdir $(srcs_tex:.tex=.pdf))
+   objs_svg := $(notdir $(srcs_svg:.svg=.pdf))
+endif
+objs := $(objs_tex) $(objs_svg)
 
 ## End of variable assignments
 
@@ -40,7 +46,7 @@
 # BUILD_DIR (optional) may contain the compiled files.
 
 ifdef $(BUILD_DIR)
-	$(objs_tex): | $(BUILD_DIR)
+	$(objs): | $(BUILD_DIR)
 
 	$(BUILD_DIR):
 		mkdir $(BUILD_DIR)

Il me semble que seuls les fichiers générés automatiquement et qui sont plus anciens que les dépendances conjuguées sont effectivement reconstruits (sauf quelconque erreur de ma part dans le Makefile).

Bonjour Salim,

Effectivement ta proposition contient pas mal de bonnes idées, J’aime beaucoup ton idée d’avoir les macros en minuscule (et d’autres idées de macros bien sympa), le Makefile parait de suite moins agressif et plus lisible.

Mais il ne sert pas les mêmes objectifs que celui que je propose :

• je me suis concentré avant tout ce pour quoi make a été créé, à savoir éviter à tout pris de recompiler ce qui existe. C’est pour cela que beaucoup de variables et macros ont un air plus abstrait (mais j’ai essayé d’expliquer son fonctionnement dans mon article) ;
• il résulte aussi de long moment à écrire du LaTeX : la cible view par exemple m’a été très utile pour voir qu’il me manquait une image par exemple. Elle n’est donc pas là parce que le Makefile pourrait défaillir. Pour résumer ce Makefile m’est avant tout destiné;
• je trouve qu’il illustre bien les concepts que j’ai expliqués dans mon premier article sur le sujet.

Je vais pas contre renommer ma variable OUTPUT en BUILD_DIR que je trouve plus parlante (dans mes prochains articles, j’ai la flemme de retoucher à celui là).

Salut ephase !

J’avais essayé de faire preuve d’esprit (pas top !). Mon point de vue est celui d’un novice ayant lu le manuel GNU Make. Je croyais que l’on pouvait améliorer nettement le Makefile à cause de l’aspect redondant ressenti. C’est la seule chose que je capte le mieux en informatique : chercher le style et l’inspiration.

Beaucoup de variables alors qu’il n’y a que peu de règles

Chemins avec une mauvaise consonance (trop significatif) dans des règles (pattern rule) : SVG_EXPORTED_DIR, OUTPUT

Maladresses techniques : default vs. all (.DEFAULT_GOAL), $(SC) vs. $(LATEX), SCFLAGS vs. LATEXFLAGS, [[IMAGES_DIR, SVG_DIR, IMAGES, SVG, OUTPUT, SVG_EXPORTED, DOCUMENTS]] à dépeindre (rentre en mauvaise consonance avec la première remarque). SC n’est pas tellement évocateur comme nom : SVG_PROGRAM. Je n’aurais pas du tout intégré les @echo ou alors dans chaque règle si nécessaire. Je pense que lorsque le Makefile est bien conçu c’est normalement superflu.

C’est difficile de proposer et bien faire les choses. Ci-dessous mon modeste essai (inachevé et approximatif).

LATEX := lualatex
LATEXFLAGS = 
SVG_PROGRAM := inkscape
SVGFLAGS = --export-type=pdf --export-pdf-version=1.4

VPATH = src:svg:bitmap

ifdef $(BUILD_DIR)
override LATEXFLAGS += --output-directory $(BUILD_DIR)
VPATH += $(BUILD_DIR)
endif

override LATEXFLAGS += --interaction=nonstopmode

srcs_tex := $(wildcard src/*.tex) 
srcs_svg := $(wildcard svg/*.svg) 
srcs_bitmap := $(wildcard bitmap/*.*)
srcs := $(srcs_tex) $(srcs_svg) $(src_bitmap)
objs_tex := $(srcs_tex:.tex=.pdf)
objs_svg := $(srcs_svg:.svg=.pdf)

## End of variable assignments

%.pdf: %.tex
	$(LATEX) $(LATEXFLAGS) $<

%.pdf: %.svg
	$(SVG_PROGRAM) $(SVGFLAGS) -o $@ $<

## End of pattern rules

.PHONY: all clean

all: $(objs_tex)

# Let's define our implicit rules

$(objs_tex): $(filter $(srcs_svg), $(srcs)) $(objs_svg)
$(objs_svg): $(srcs_svg)

# BUILD_DIR (optional) may contain the compiled files.

ifdef $(BUILD_DIR)
$(objs_tex): | $(BUILD_DIR)

$(BUILD_DIR):
	mkdir $(BUILD_DIR)

clean:
	-rm -r $(BUILD_DIR)
else
clean:
	-rm $(objs)
endif

Bonsoir Salim,

Après avoir passé pas mal de temps à travailler sur les Makefile, je ne trouves pa que l’on pert en clarté. Il faut pas contre avoir pratiqué.

Personnellement je ne trouves pas que les instructions view et info soient inadaptées ici, elles me sont utile au quotidien (je ne suis sûrement pas objectif).

Pour les variables, la coutume est l’utilisation des majuscule (Comme pour les variables d’environnement), j’ai donc choisi de la conserver. Les nom des cibles sont eux en minuscule. Il n’y a pas de répertoire document ici, seulement le dossier output dont l’utilité est expliquée dans l’article.

La façon d’organiser un Makefile et de garantir au maximum qu’on ne compile seulement ce qui doit être compilé rend les choses moins lisibles effectivement, mais je trouves que c’est tellement plus pratique et portable.

J’utilise codium pour publier la newsletter du Courrier du hacker. Je le trouve assez efficace.

On perd sacrément en clarté sans script Shell, n’est-ce pas ?

Les instructions info et view (bad targets in english) sont inadaptées dans un Makefile. No viewer or man to help (this is automatic). ;-)

J’ai comme un doute sur les variables : choix des noms, en majuscule / minuscule. Pourquoi donc associer un préfixe (c.f. addprefix) à des répertoires nommés « documents » et « output » ? Simplification possible ?

La façon de constituer les choses est un mystère (unknown recipe). Évidemment, on pourrait intégrer les instructions qui disparaîtraient éventuellement du Makefile dans le script Shell. Ne me demandez pas comment.

Ça manque un peu de bench pour voir si en pratique ça change vraiment quelque chose…

En 2015 j’avais acheté un Raspberry Pi 2B avec l’idée d’en faire un serveur Web. En 2019 j’avais acheté un Raspberry Pi 4B en remplacement de mon ancien ordinateur de travail avec mon budget limité. Je ne me souviens plus à partir de quand, mais à l’origine, on ne pouvait pas démarrer de SE avec un disque branché en USB. Durant cette période, je souhaitais également installer GNU Guix sur le RPi 4. C’est dans ce contexte que j’ai découvert que le projet GNU (avec la GNU FSDG) dissuadait fortement l’usage des appareils courants en limitant la prise en charge du matériel non libre équipé de micrologiciels privateurs. Ces ordinateurs monocartes basés sur l’architecture ARM ont leurs spécificités. Ils sont à la croisée des chemins en terme d’usages. Trop compliqué pour moi. Et difficile à concilier. Cela m’a donné l’impression que chacun avait son domaine de prédilection. En présentant deux objectifs contraires : normaliser un produit pour l’industrie ou rendre un produit accessible pour l’éducation à informatique. Parce que les gens qui utilisaient des Raspberry Pi ce n’était pas vraiment des amateurs en micro-informatique. Du coup, en ayant vu différents usages du RPi, dont certains ne semblent pas si pertinents au niveau fonctionnel, on peut s’interroger du bien-fondé de la démarche qui consiste à ajouter un disque SSD à un RPi, étant donné que ce n’est mentionné nul part dans l’article.

Oui, jusqu’à ce que tu “déranges” un peu trop à son goût un des administrateurs et tu te fais bannir du salon matrix dédié, parce que tu demandes de l’aide de “manière trop insistante” pour lui !

J’en parle sur Mastodon ou D* ; d’autant que je n’ai en rien été désagréable, résultat je ne peux pas récupèrer mon compte ; aucun moyen réel de communiquer avec les administrateurs ; donc perte des deux communautés FR que j’ai créées, sans parler du reste !

:(

Bref, ce qui était d’un intérêt moyen finit par être une mauvaise expérience, et ce sans être (passif-)agressif, désobligeant. Dommage ! :(

Deux ans d’expérience figée…

Alors, oui, je peux très bien créer sur une autre instance, mais faut avouer que ça fait désordre !