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.
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 ?
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.
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).
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à).
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).
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.
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.
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 !
Je ne suis pas tellement convaincu par votre explication. En théorie, on pourrait définir la spécificité des règles CSS en appliquant des sélecteurs adéquats et en plaçant les déclarations CSS dans les règles appropriées. En cas de conflit dans les déclarations, il n’y a pas de surcharge, c’est par exemple la déclaration CSS la plus spécifique qui s’applique (le principe de la cascade : combiner des déclarations CSS). Je veux bien croire que les noms de classes sont exploités par des outils automatisés pour effectuer des analyses sémantiques mais je ne pense pas qu’en tant que tel les noms de classes aient véritablement un rôle sémantique (à mon avis, ce sont plutôt des indicateurs). Après, je pense que isolément, cela peut-être plus évident à lire avec des noms de classe spécifiques comme par exemple .article-preview, dans une feuille de style. Dans le fichier HTML, c’est moche (parce que superflu). Graphiquement, je ne sais pas si on ne perd pas en corrélation sur la complémentarité CSS / HTML. C’est juste une intuition, je ne sais rien sinon, car je n’ai pas d’expérience.
C’est vrai qu’on pourrait s’en contenter - encore plus dans le contexte d’un petit test isolé comme celui-ci. Mais malgré tout peut être que je l’ai mal nommé ici. Sûrement que dans un vrai projet j’aurai nommé ma classe “article-preview” par exemple.
Par contre l’inconvénient de la méthode est que tu proposes est que ça va augmenter de manière assez forte la spécificité de ton sélecteur CSS. Du coup si demain tu as besoin de surcharger la classe pour une raison ou une autre ça risque de te compliquer la tâche. Ça devient aussi plus facile de repérer quel code n’est plus utilisé et peut être supprimé au cours de l’évolution d’un projet.
Pour quoi nommer des classes comme « article » ? C’est une façon de désigner les choses qui est très générique. Les éléments sont déjà nommés comme cela ou peuvent être désignés de la même manière.
Ce tutoriel sort du lot (innombrable) qu’on peut trouver sur internet, et pour une raison: il y a des ajouts de sécurité pas déconnant au niveau d’Apache qui sont évoqués, et c’est une très bonne chose. Merci pour cet article.
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.C’est pas bien !
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éfixessrc/etsvg/commesrc/foo.pdfau lieu defoo.pdfou bien$(BUILD_DIR)/foo.pdf.Édition :
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 vais pas contre renommer ma variable
OUTPUTenBUILD_DIRque 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.
C’est difficile de proposer et bien faire les choses. Ci-dessous mon modeste essai (inachevé et approximatif).
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
outputdont 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
infoetview(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 !
Je ne suis pas tellement convaincu par votre explication. En théorie, on pourrait définir la spécificité des règles CSS en appliquant des sélecteurs adéquats et en plaçant les déclarations CSS dans les règles appropriées. En cas de conflit dans les déclarations, il n’y a pas de surcharge, c’est par exemple la déclaration CSS la plus spécifique qui s’applique (le principe de la cascade : combiner des déclarations CSS). Je veux bien croire que les noms de classes sont exploités par des outils automatisés pour effectuer des analyses sémantiques mais je ne pense pas qu’en tant que tel les noms de classes aient véritablement un rôle sémantique (à mon avis, ce sont plutôt des indicateurs). Après, je pense que isolément, cela peut-être plus évident à lire avec des noms de classe spécifiques comme par exemple
.article-preview, dans une feuille de style. Dans le fichier HTML, c’est moche (parce que superflu). Graphiquement, je ne sais pas si on ne perd pas en corrélation sur la complémentarité CSS / HTML. C’est juste une intuition, je ne sais rien sinon, car je n’ai pas d’expérience.C’est vrai qu’on pourrait s’en contenter - encore plus dans le contexte d’un petit test isolé comme celui-ci. Mais malgré tout peut être que je l’ai mal nommé ici. Sûrement que dans un vrai projet j’aurai nommé ma classe “article-preview” par exemple.
Par contre l’inconvénient de la méthode est que tu proposes est que ça va augmenter de manière assez forte la spécificité de ton sélecteur CSS. Du coup si demain tu as besoin de surcharger la classe pour une raison ou une autre ça risque de te compliquer la tâche. Ça devient aussi plus facile de repérer quel code n’est plus utilisé et peut être supprimé au cours de l’évolution d’un projet.
La méthode que j’ai utilisé ici est https://getbem.com/introduction/
Pour quoi nommer des classes comme « article » ? C’est une façon de désigner les choses qui est très générique. Les éléments sont déjà nommés comme cela ou peuvent être désignés de la même manière.
Ce tutoriel sort du lot (innombrable) qu’on peut trouver sur internet, et pour une raison: il y a des ajouts de sécurité pas déconnant au niveau d’Apache qui sont évoqués, et c’est une très bonne chose. Merci pour cet article.