Threads for ephase | Journal du hacker

1

salim édité plus d'un an | lien | sur : Utiliser make pour compiler ses documents LaTeX

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.
1. 1
  
  ephase plus d'un an | lien
  
  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.
  1. 1
    salim édité plus d'un an | lien
    
    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
    1. 2
      
      ephase plus d'un an | lien
      
      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à).
      1. 1
        
        salim édité plus d'un an | lien
        
        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).
    2. 1
      
      salim édité plus d'un an | lien
      
      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)

4
PengouinPdt il y a 2 ans | lien | sur : Bash avancé: It’s a trap!
Bjr. Tout d’abord, merci pour ces explications claires, limpides. Je ne m’étais jamais mis à la question, mais récemment je me suis fait la réflexion de l’intérêt de la chose. Grâce à toi, j’ai compris le propos. Merci !

Sinon quelques coquilles :
- tous les signaux ne peuvent pas être piégé <= piégés.
- concret: <= concret : (nécessite un espace toujours devant les deux points)
- la connexion maitre <= la connexion maître
- intiée <= initiée
- un signal standards su système <= un signal standard du système (pas de ‘s’ final à standard; + su/du)
- ce qui ga générer <= ce qui va générer
- changer se comportement <= changer ce comportement
- problème: (voir remarque plus haut, concernant les deux points)
- Dans notre script nous allons modifier un petit peu notre script (une certaine redondance qui alourdit le propos : proposition : Modifions un petit peu notre script.)
- prévu: (voir remarque plus haut, concernant les deux points)
- répétition : “Afin de disposer de plus de temps pour lancer la commande kill
Afin d’avoir le temps de lancer la commande kill,”
- PID: (voir remarque plus haut, concernant les deux points)
- signal:
- comment en intercepter <= comment l’intercepter
;)
1. 3
  
  ephase il y a 2 ans | lien
  
  Bonjour PengouinPdt, merci pour ces corrections. Et merci aussi pour le retour, c’est toujours agréable de voir que mon travail sert et est apprécié :).

1

ephase il y a 2 ans | lien | sur : Bash avancé: It’s a trap!

Bonjour Salim, J’avoue, le mot piège est le prétexte pour faire le jeux de mot sur la célèbre phrase du Général Ackbar. Mais je suis d’accord avec vous.

Pour ce qui est de la complexité des script, tout dépend du point de vue. personnellement en tant qu’administrateur système je suis plus à l’aise avec des scripts shell qu’avec d’autre type de languages.