Merci de ton retour. Je vais aller consulter les liens et éditer l’article pour ajouter ces informations.

Aucune mention des sources de cette fonction et de pourquoi elle existe. :( C’est dommage, rien qu’un mot sur ses origines de programmation fonctionnelle aurait augmenter la qualité de l’article.

https://en.wikipedia.org/wiki/Fold_(higher-order_function)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduceRight

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…