Merci pour le pointeur, je vais regarder ce que sait faire inotify.
Incidemment, le cas d'usage de lk-reducer est très intéressant: Il s'agit, si j'ai bien compris, de nettoyer une arborescence kernel de tous les fichiers qui trainent mais ne servent plus.
On lance sous monitoring un make et un make mrproper, et ensuite on repère les fichiers qui n'ont pas été accédé pendant le make, et qui ne sont pas nettoyé par le make mrproper.
Je ne me suis intéressé qu'aux fichiers lus ou écrits, mais en effet, dans ce cas les fichiers non accédés sont une info intéressante! Je le note comme un ajout fonctionnel possible à smk: après un build, on pourrait demander à smk quels fichiers d'une arborescence n'ont pas été concerné par ce qui a été exécuté.
L'autre point pas inintéressant, c'est le mode interactif: je lance un shell, et c'est tout ce qui est exécuté pendant que je suis dans ce shell qui est observé. Le fichier de log qui classe les fichiers en "Accessed, Untouched, or Generated" est écrit à la sortie du shell. Les commandes sont donc analysées comme une opération unique, puisque c'est ce qui nous intéresse ici.
Pas encore sûr d'en faire quelque chose, mais je le note!
On ne peut pas dire que smk "oublie", puisque ce que tu décrit n'est pas du tout la cible visée par l'outil, et que c'est indiqué clairement à plein d'endroit sur le site, dans l'article et dans mes réponses. Je rappelle le créneau : simplicité, universalité.
Je n'ai aucune intention de refaire un bmake.
(D'ailleurs, si le créneau n'était pas celui là, j'aurai juste arrêté le projet et conseiller l'usage de fabricate, que j'ai découvert par les réponses dans ce journal).
La ou je suis moins pessimiste que toi sur l'utilité même pour un grand programme, c'est que je vois très bien en revanche un smkfile lister les commandes à exécuter pour le packaging, l'installation et la désinstallation, etc.
Je te dirais même que pour la désinstallation par exemple, comme smk connait tous les fichiers qui ont été créé par l'installation, y a moyen que ce soit redoutablement simple.
Merci pour l'idée, je vais voir si je peux en faire un cas de test (qui ne sera pas simple, car comment gérer les updates de fichiers existant?, mais bon, bonne idée en tout cas).
Oui, je suis d'accord sur la politique générale: offrir un voie pour permettre de faire tout ce que tu n'as pas envie de prendre en compte directement permet de ne pas bloquer l'usage de l'outils à cause d'une impossibilité fonctionnelle.
Je vais garder le cas d'usage du re-run de Latex de chimrod dans la whish list, auquel j'essaierai surement d'arriver par des étapes plus simples.
Hello Nokomprendo, oui, il pourrait.
Mais le but est ici pédagogique, faire clair avant de faire court. Si dans mon tuto une commande est lancée, j'aime autant qu'elle apparaisse en clair dans le Makefile ainsi que les fichiers concernés.
Et pour les variables, j'en utiliserai dans le Makefile d'exemple dès que smk saura les traiter (ce que j'ai annoncé vaillamment pour Noël un peu plus haut!).
Ah oui, très bonnes idées!
Et pour moi pour illustrer l'utilisation de smk sans faire dans le gcc!
Ça me fait penser que j'ai un cas aussi : j'utilise rapid photo downloader pour renommer et classer toutes les photos que j'archives.
Quelque soit l'origine, je déverse tout dans le même répertoire tmp "à classer", et rapid s'occupe du reste.
Je vais tester smk:
- répertoire tmp vide, ne doit rien faire
- répertoire tmp plein de photos déjà traitées, ne doit rien faire
- répertoire tmp avec des photos inconnues -> run
Et pour le besoin d'outils type backintime, qui sauvegardent leur propre configuration et que l'on peut lancer quasiment sans options sur la ligne de commande, pas la peine de faire un fichier smkfile, je vais prévoir le lancement directement en ligne de commande, type smk backintime --backup-job.
Oui, on m'en a parlé quand je suis sorti du bois il y a un mois avec mon idée.
Mais même si le système est très intéressant, il oblige à créer un tupfile.
Par exemple pour
"gcc hello.c -o hello", le tupfile contiendra
": hello.c |> gcc hello.c -o hello |> hello"
C'est donc l'utilisateur qui donne la règle de production avec ce format source|commande|target.
C'est une syntaxe différente Make, mais c'est la même idée.
smk vise à se passer complètement de cette description.
Merci pour le papier mtime comparison considered harmful, j'ai appris plein de chose, et découvert qu'un des défauts que je mettais dans limitations est aussi un défaut de make.
Je ne suis pas rentré dans le mécanisme de redo, je n'ai pas trouvé d'explication claire et concise.
redo's design fundamentally depends on keeping a database of targets, if only to remember which files were produced by redo and which were not. From there, it's easy enough to extend that database to include mtime information about sources.
Ca à l'air de ressembler à ce que stocke smk, mais je ne peut pas en dire plus.
Le mécanisme à l'air très safe, mais la syntaxe est trop compliqué pour moi. Quand je vois dans l'intro ce qu'il faut écrire pour lancer un pauvre gcc, ça ne me donne pas envie d'aller plus avant.
Je comprends que le mécanisme permet d'éviter qu'une source soit considérée comme valide alors qu'il s'agit d'un fichier intermédiaire (parce que la compilation a été interrompue au milieu, par exemple).
Pour les cas simples que je vise, cela ne justifie pas la complexité ajoutée autour de la commande gcc.
Après, sur le fait d'avoir les cibles all clean etc. éclatés en plusieurs fichier script dans le répertoire courant, je ne suis pas hostile, et je propose de faire la même chose avec smk, mais le contenu des fichiers doit rester très simple.
Pour répondre à ta question : en effet, je m'appuie sur mtime pour savoir si un fichier a été modifié depuis la dernière exécution de la commande, mais pas pour distinguer les inputs des outputs. C'est ce que faisait ma première version, date fichier < heure d'exécution => source, date fichier > heure exécution => target. Mais la ça dysfonctionnait carrément pour les problèmes évoqué dans l'article, au moins celui de granularité faible du mtime).
Il n'en reste pas moins que la version actuelle souffre encore (marginalement) de ce défaut dans un cas bien précis également décrit dans l'article:
Computers are now so fast that you can save foo.c in your editor, and then produce foo.o, and then compile foo, all in the same one-second time period. If you do this and, say, save foo.c twice in the same second (and you have one-second granularity mtimes), then make can't tell if foo.o and foo are up to date or not.
Comme c'est ce que je fait dans les tests de smk, j'ai du mettre à deux endroits "sleep 1" dans le Makefile pour ne pas tomber dans ce bug. Mais grâce à ton lien, je vois ce que fait redo pour éviter ça (par exemple stocker et comparer également la taille), c'est une très bonne source, merci.
Merci à toi pour l'info (et à Michaël).
L'exploration de bmake et du méta mode a été très intéressante!
Voici mon retour:
l'outil repose sur filemon. filemon est un device spécial qui permet de collecter toutes les opérations fichier d'un process et de ses fils.
Il a été pensé exprès pour l'usage d'outils de build, et il est expliqué que ktrace permet de le faire, mais que ktrace capture tout, et qu'il faudrait ensuite filtrer dans un énorme log (info peut-être pas à jour). (sur Linux, strace traite le problème, puisqu'on lui dit sur la ligne de commande "-e trace=file"). Il est dit également que le proto de bmake utilisait un autre équivalent de strace, DTrace. Mais celui-ci exigeait des privilèges root.
Pour info, existe sur GitHub un port de filemon sur Linux.
bmake est pensé pour reconstruire FreeBSD sur toutes les plateformes. Autant dire que c'est au antipode de smk en terme de complexité de cible:
While meta mode may be the coolest thing since sliced bread, it may not be for everyone. It does provide a simple solution to some rather complex problems
Mais surtout bmake reste un make : sa syntaxe relève du grand art, (tu l'écrit le lundi, le mardi tu ne comprends plus ce que tu as écrit, le mercredi tu te demande qui est le con qui a été piqué ce code dans un obfuscation contest!). Personne n'a envie de ça pour un outils simple.
Et vice versa, smk ne fera jamais la moitié de ce que fait bmake.
j'ai trouvé également intéressant de voir ce que stockait bmake dans ses fichiers .meta (l'équivalent des runfiles smk). Comme pour smk, y sont stockés la commande et ses options, et les fichiers classés en read et write, mais aussi quelques autres infos, comme le répertoire d'exécution.
Je retiens l'idée d'un format de fichier en clair (texte), pour faciliter le debug. Pour l'instant, smk c'est du binaire. Je vérifierai l'impact en performance de ce changement, mais si c'est faible, je ferais le switch.
fabricate a un argumentaire de vente que je pourrais reprendre tel quel :-)
J'ai bien noté l'utilisation de strace, ou des time tags, ainsi que celle de MD5 pour vérifier si un fichier a changé, intéressant.
De même que l'autoclean, évidemment.
C'est l'outil le plus proche de smk que j'ai vu a date, et il est bien plus puissant. Mais il s'agit plus d'une lib que d'un exe (même si on peut l'invoquer en ligne en lui passant tout en paramètre) : pour l'utiliser dans toute ses possibilités, il faut écrire son script de build en Python.
(Même remarque pour Shake-Forward, sauf que la il faut scripter en haskell).
Donc ça confirme que l'on peut faire smk depuis au moins dix ans. Reste la forme, je pense qu'ils ne sont pas sur le même créneau simplicité - universalité.
Merci Guillaum, très intéressant, je vais aller voir les références.
Pour ce qui est du problème du build initial, effectivement, convertir un énorme projet à cette approche peut poser problème si le temps total de build est en jours (même si on peut toujours réfléchir à une conversion progressive, en insérant progressivement smk dans les makefiles existants).
Par contre, le stockage de smk est fait ainsi :
pour chaque smkfile, chaque couple sources/cibles est indexé par la ligne de commande. Donc si tu rajoutes une commande, ça rajoute une entrée, et si tu modifies une commande, idem. Il n'y a donc pas a ré-exécuter tout à chaque mise à jour du smkfile, et donc pas de problème pour croître avec le projet.
Il faut juste que j'ajoute dans ma suite un test pour vérifier que le runfile n'enfle pas quand on le fait de façon répétitive avec des lignes de commandes "mortes" qui ne figurent plus dans le smkfile. Je vais m'enregistrer une issue pour penser à traiter ce problème.
Il n'y a pas vraiment de raison, j'ai juste repris les exemples de ce tuto
Après je pense que c'est plus clair pour comprendre ces histoires de sources et de cibles d'avoir les cibles de façon explicite dans la ligne de commande.
Mais on est bien d'accord que ça ne change rien pour smk, puisque l'outils regarde les fichiers réellement accédés, pas la ligne de commande ni le smkfile.
Hello, pas sur de comprendre ta question le calcul de dépendance, tu parles bien du cas ou l'output d'une commande invalide l'input d'une autre?
Dans ce cas, oui, c'est fait.
L'implémentation est naïve aujourd'hui, car je n'ai pas implémenté de graphe de dépendance.
C'est fait ainsi : je parcours la liste des commandes, si l'une d'entre elle est exécutée, alors je re-parcours toute la liste. Quand plus aucune commande n'est exécutée, je sors.
Pour éviter des cas pathologiques de dépendances récursives, le nombre de boucles est limité au nombre de commande, qui est le max du worst-case.
Pas forcément optimal en terme de perf, mais tellement plus simple à coder dans un premier temps.
Sur le second point, justement l'overhead, pas encore de mesure à ce point. Mais vu que vous êtes plusieurs à poser la question, je ferai un "time" comparatif d'un Makefile et d'un smkfile équivalent
(j'ai créé une issue sur GitHub).
Du coup en te basant sur les appels systèmes pour déterminer les dépendances (et sans faire d'optimisations propre au langage pour rester agnostique) j'aurai tendance à croire à un gros overhead (aussi bien en temps qu'en taille de logs dans tes fichiers .smk.*).
Tu as des chiffres là dessus ?
Non, et je n'ai pas envie de me lancer dans ces mesures tant que je n'aurai pas les idées claires sur l'intérêt de l'outil, et sur son domaine d'emploi.
Dans mon intention, l'idée principale est de gagner du temps lors de l'écriture / l'automatisation du process.
A première vue, l'exécution est rapide.
Mais peut-être que sur mes cas de tests simple, l'overhead est supérieur au temps d'exécution d'une commande gcc que l'on cherche à éviter, c'est tout à fait possible!!
(en taille de fichier, ça reste négligeable, mais je n'ai pas encore mis dans ma suite de test un gros build avec plein de fichier lu et écrits, type prod de site web).
J'imagine que tu n'as pas pu résister à l'envie de compiler smk avec smk ;-)
Bien sûr :-)
Mais mon Makefile est déjà trop complexe. Par exemple, je pipe des commandes les unes dans les autres sur certaines lignes. Et smk ne sait pas lancer de shell, juste des commandes.
Et bien sûr j'utilise des variables, pas encore supportées non plus.
Mais je garde en tête cet objectif, qui est de faire la même chose que mon Makefile, et de voir si j'y arrive vraiment de façon plus simple.
Merci pour le journal et le projet, ça fait très plaisir de voir une approche audacieuse à un problème ancien ;-)
Merci!
Dans mes souvenir un pauvre hello world en C++ se retrouve tout de suite avec des tonnes d'includes en cascade, dont beaucoup ne sont des bibliothèques standards fournies par le compilo (donc ne devant jamais changer en théorie…).
Oui, c'est amusant dans mon exemple de voir que pour gcc -o hello.o -c hello.c, il y a 55 fichiers accédés en read, alors qu'un seul nous intéresse, hello.c!
D’ou mon choix d'ignorer par défaut les fichiers systèmes dans les affichages, sinon c'était illisible.
(pour voir les fichiers systèmes, il y a une option --shows-all-files)
Par contre, tous les fichiers sont bien pris en compte: si /usr/include/stdio.h est mis à jour, la recompilation sera bien faite.
oui, on m'a déjà fait des retours de ce type (je crois même que c'est l'issue #1 sur GitHub!).
Je ferai une section "hints", donnant quelques commandes habituelles pour générer les dépendances, c'est toujours intéressant, mais ce sera pour mieux préciser que ce n'est pas la cible de smk.
Je ne prétends pas faire mieux qu'un outil dédié qui recompile ce qui doit l'être (comme gprbuild que j'utilise pour le code de smk), et qui peut même faire une analyse sémantique des sources et ne pas recompiler si par exemple seul les commentaires ont étés modifiés.
L'idée est plutôt d'optimiser des enchaînements de commandes plus simple (le make complexe de compilation pouvant d'ailleurs être une de ces commandes), avec un outil universel (non dépendant de la sémantique de ce qui est construit).
Cela montre l'urgence d'avoir dans ma doc d'autres exemples que du build gcc!
Est-ce que tu vois un intérêt à l'outil pour des choses autres, que tu traiterais par exemple par shell script?
(et merci en tout cas pour le retour)
Merci Adrien pour ta super appréciation sur l'idée!
Mon intention est de limiter au maximum le travail fait pour être compatible avec un shell file ou un Makefile.
Mais j'ai posté ce journal exactement pour avoir ce genre de retour.
Je suppose que tu fait allusion aux lignes du genre:
CFLAGS=-W -Wall -ansi -pedantic
Oui, je ne suis pas sûr de pouvoir passer au travers.
J'y ai réfléchi, et la partie substitution de variable n'est pas si compliquée, je créé une entrée dans github pour m'y atteler pendant les vacances de Noël!
la force de l'outils, c'est qu'il est complètement indépendant des commandes exécutées.
Il n'a pas la moindre idée de ce qui est compilé, il ne sait même pas si c'est de la compilation, et c'est tout à fait ce que je veux.
Il fonctionne donc aussi bien avec Fortran qu'avec n'importe quel langage y compris pas encore inventé (sauf à ce que les sources ne soient pas dans des fichiers).
J'ai utilisé un build typique C, mais c'est par facilité parce que c'est ce que l'on trouve dans tout les tutos de make.
En fait, je suis aussi preneur d'autres scripts que vous auriez, pour varier mes exemples et mes tests, comme par exemple la production de sites web, ou de documents, type:
latex <file>.tex
dvips <file>.dvi
ps2pdf <file>.ps
pdf2eps <pagenumber> <file>
En fait, ce n'est pas dans le cas du SSD une optimisation de performance, mais une optimisation de durée de vie.
Ma compréhension est qu'avec l'algo deadline, il y a moins de chance de se trouver dans la situation d'une écriture de bloc, suivie dans la milliseconde de la réécriture du même bloc parce que un second write a été fait sur d'autres octets dans la même zone.
Pour les DD on voulait optimiser le point faible : la mécanique. Pour les SSD on veut réduire les write, mais le principe reste le même, regrouper les écritures par bloc.
Bien sûr, je n'ai aucun moyen de vérifier si cela a un impact réel sur la durée de vie, c'est pourquoi je disais faire confiance (même si ce cas pathologique de réécriture me semble un peu théorique).
Pour ma référence à l'expérimentation à la fin de ce même paragraphe, je pensais à l'algo noop : les premiers tests, qu'il faut prendre avec des pincettes, semble en effet confirmer que cet algo plus simple donne les mêmes performances que les deux autres sur un SSD.
Mais d'un autre côté, sa simplicité n'occasionne pas des gains de CPU substantiels qui à leur tour amélioreraient les performances (ce qui est normal, puisque sur nos PC de bureau, SSD ou pas SSD la CPU n'est toujours pas le maillon faible, l'optimiser dans les coins ne sert donc pas à grand chose).
Après, si quelqu'un veut dérouler le script donné plus haut sur un DD pour voir si ce paramètre change les choses, ce pourrait être intéressant dans les situation mixte DD/SSD car on peut faire un choix d'algo différent par device.
Merci pour le truc,je vais essayer.
Pour éviter aux lecteurs de chercher comme je viens de le faire, echo 3 dans ce paramètre free pagecache, dentries and inodes.
Maintenant, le but étant d'évaluer l'impact de certain réglages relatifs au SSD sur les performances dans des conditions réelles, là on s'en éloigne un peu.
Au pire la première compilation sera plus lente que les suivantes, mais quant on code, on en fait en général quelques une à la suite, donc au total l'impact ne devrait pas être marquant.
Le j c'est par réflexe, je ne voulais pas m'en servir dans la boucle.
Mais ton idée d'un -j64 est excellente (quoi que je doute que gcc arrive à en faire autant en // sur ce code pas si gros que ça).
J'ai un rdiff-backup qui tourne tous les soirs sur un DD dédié au backup, donc une panne totale n'aurait pas d'effet catastrophique.
Mais surtout, cela rejoint les considération générales sur la fiabilité des SSD : je pense qu'on a maintenant un recul suffisant (mais je me fait peut-être des idées…) pour supposer que leur fiabilité est supérieure à celle des DD classique, et ce sur une durée raisonnablement longue.
Par ailleurs, j'ai bien regardé les retour d'expérience sur les SSD, et j'ai choisi un beau modèle (pas à un prix plancher), sans problème connu de fiabilité.
[^] # Re: inotify vs ptrace
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 2.
Merci pour le pointeur, je vais regarder ce que sait faire inotify.
Incidemment, le cas d'usage de lk-reducer est très intéressant: Il s'agit, si j'ai bien compris, de nettoyer une arborescence kernel de tous les fichiers qui trainent mais ne servent plus.
On lance sous monitoring un make et un make mrproper, et ensuite on repère les fichiers qui n'ont pas été accédé pendant le make, et qui ne sont pas nettoyé par le make mrproper.
Je ne me suis intéressé qu'aux fichiers lus ou écrits, mais en effet, dans ce cas les fichiers non accédés sont une info intéressante! Je le note comme un ajout fonctionnel possible à smk: après un build, on pourrait demander à smk quels fichiers d'une arborescence n'ont pas été concerné par ce qui a été exécuté.
L'autre point pas inintéressant, c'est le mode interactif: je lance un shell, et c'est tout ce qui est exécuté pendant que je suis dans ce shell qui est observé. Le fichier de log qui classe les fichiers en "Accessed, Untouched, or Generated" est écrit à la sortie du shell. Les commandes sont donc analysées comme une opération unique, puisque c'est ce qui nous intéresse ici.
Pas encore sûr d'en faire quelque chose, mais je le note!
[^] # Re: Une amélioration possible
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 2.
Bonjour Benoar,
On ne peut pas dire que smk "oublie", puisque ce que tu décrit n'est pas du tout la cible visée par l'outil, et que c'est indiqué clairement à plein d'endroit sur le site, dans l'article et dans mes réponses. Je rappelle le créneau : simplicité, universalité.
Je n'ai aucune intention de refaire un bmake.
(D'ailleurs, si le créneau n'était pas celui là, j'aurai juste arrêté le projet et conseiller l'usage de fabricate, que j'ai découvert par les réponses dans ce journal).
La ou je suis moins pessimiste que toi sur l'utilité même pour un grand programme, c'est que je vois très bien en revanche un smkfile lister les commandes à exécuter pour le packaging, l'installation et la désinstallation, etc.
Je te dirais même que pour la désinstallation par exemple, comme smk connait tous les fichiers qui ont été créé par l'installation, y a moyen que ce soit redoutablement simple.
Merci pour l'idée, je vais voir si je peux en faire un cas de test (qui ne sera pas simple, car comment gérer les updates de fichiers existant?, mais bon, bonne idée en tout cas).
[^] # Re: seulement pour du C ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 1.
Oui, je suis d'accord sur la politique générale: offrir un voie pour permettre de faire tout ce que tu n'as pas envie de prendre en compte directement permet de ne pas bloquer l'usage de l'outils à cause d'une impossibilité fonctionnelle.
Je vais garder le cas d'usage du re-run de Latex de chimrod dans la whish list, auquel j'essaierai surement d'arriver par des étapes plus simples.
[^] # Re: avec les règles automatiques de make
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 1.
Hello Nokomprendo, oui, il pourrait.
Mais le but est ici pédagogique, faire clair avant de faire court. Si dans mon tuto une commande est lancée, j'aime autant qu'elle apparaisse en clair dans le Makefile ainsi que les fichiers concernés.
Et pour les variables, j'en utiliserai dans le Makefile d'exemple dès que smk saura les traiter (ce que j'ai annoncé vaillamment pour Noël un peu plus haut!).
[^] # Re: Une alternative à l'alternative
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3.
Ah oui, très bonnes idées!
Et pour moi pour illustrer l'utilisation de smk sans faire dans le gcc!
Ça me fait penser que j'ai un cas aussi : j'utilise rapid photo downloader pour renommer et classer toutes les photos que j'archives.
Quelque soit l'origine, je déverse tout dans le même répertoire tmp "à classer", et rapid s'occupe du reste.
Je vais tester smk:
- répertoire tmp vide, ne doit rien faire
- répertoire tmp plein de photos déjà traitées, ne doit rien faire
- répertoire tmp avec des photos inconnues -> run
Et pour le besoin d'outils type backintime, qui sauvegardent leur propre configuration et que l'on peut lancer quasiment sans options sur la ligne de commande, pas la peine de faire un fichier smkfile, je vais prévoir le lancement directement en ligne de commande, type
smk backintime --backup-job.Merci pour les idées!
[^] # Re: tup
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3. Dernière modification le 12 décembre 2018 à 00:51.
Oui, on m'en a parlé quand je suis sorti du bois il y a un mois avec mon idée.
Mais même si le système est très intéressant, il oblige à créer un tupfile.
Par exemple pour
"gcc hello.c -o hello", le tupfile contiendra
": hello.c |> gcc hello.c -o hello |> hello"
C'est donc l'utilisateur qui donne la règle de production avec ce format source|commande|target.
C'est une syntaxe différente Make, mais c'est la même idée.
smk vise à se passer complètement de cette description.
[^] # Re: Et par rapport à redo ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3.
Merci pour le papier mtime comparison considered harmful, j'ai appris plein de chose, et découvert qu'un des défauts que je mettais dans limitations est aussi un défaut de make.
Je ne suis pas rentré dans le mécanisme de redo, je n'ai pas trouvé d'explication claire et concise.
Ca à l'air de ressembler à ce que stocke smk, mais je ne peut pas en dire plus.
Le mécanisme à l'air très safe, mais la syntaxe est trop compliqué pour moi. Quand je vois dans l'intro ce qu'il faut écrire pour lancer un pauvre gcc, ça ne me donne pas envie d'aller plus avant.
Je comprends que le mécanisme permet d'éviter qu'une source soit considérée comme valide alors qu'il s'agit d'un fichier intermédiaire (parce que la compilation a été interrompue au milieu, par exemple).
Pour les cas simples que je vise, cela ne justifie pas la complexité ajoutée autour de la commande gcc.
Après, sur le fait d'avoir les cibles all clean etc. éclatés en plusieurs fichier script dans le répertoire courant, je ne suis pas hostile, et je propose de faire la même chose avec smk, mais le contenu des fichiers doit rester très simple.
Pour répondre à ta question : en effet, je m'appuie sur mtime pour savoir si un fichier a été modifié depuis la dernière exécution de la commande, mais pas pour distinguer les inputs des outputs. C'est ce que faisait ma première version, date fichier < heure d'exécution => source, date fichier > heure exécution => target. Mais la ça dysfonctionnait carrément pour les problèmes évoqué dans l'article, au moins celui de granularité faible du mtime).
Il n'en reste pas moins que la version actuelle souffre encore (marginalement) de ce défaut dans un cas bien précis également décrit dans l'article:
Comme c'est ce que je fait dans les tests de smk, j'ai du mettre à deux endroits "sleep 1" dans le Makefile pour ne pas tomber dans ce bug. Mais grâce à ton lien, je vois ce que fait redo pour éviter ça (par exemple stocker et comparer également la taille), c'est une très bonne source, merci.
[^] # Re: Meta mode de FreeBSD
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3. Dernière modification le 11 décembre 2018 à 23:03.
Merci à toi pour l'info (et à Michaël).
L'exploration de bmake et du méta mode a été très intéressante!
Voici mon retour:
l'outil repose sur filemon. filemon est un device spécial qui permet de collecter toutes les opérations fichier d'un process et de ses fils.
Il a été pensé exprès pour l'usage d'outils de build, et il est expliqué que ktrace permet de le faire, mais que ktrace capture tout, et qu'il faudrait ensuite filtrer dans un énorme log (info peut-être pas à jour). (sur Linux, strace traite le problème, puisqu'on lui dit sur la ligne de commande "-e trace=file"). Il est dit également que le proto de bmake utilisait un autre équivalent de strace, DTrace. Mais celui-ci exigeait des privilèges root.
Pour info, existe sur GitHub un port de filemon sur Linux.
bmake est pensé pour reconstruire FreeBSD sur toutes les plateformes. Autant dire que c'est au antipode de smk en terme de complexité de cible:
Mais surtout bmake reste un make : sa syntaxe relève du grand art, (tu l'écrit le lundi, le mardi tu ne comprends plus ce que tu as écrit, le mercredi tu te demande qui est le con qui a été piqué ce code dans un obfuscation contest!). Personne n'a envie de ça pour un outils simple.
Et vice versa, smk ne fera jamais la moitié de ce que fait bmake.
[^] # Re: Quid des perfs ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 2. Dernière modification le 12 décembre 2018 à 07:53.
fabricate a un argumentaire de vente que je pourrais reprendre tel quel :-)
J'ai bien noté l'utilisation de strace, ou des time tags, ainsi que celle de MD5 pour vérifier si un fichier a changé, intéressant.
De même que l'autoclean, évidemment.
C'est l'outil le plus proche de smk que j'ai vu a date, et il est bien plus puissant. Mais il s'agit plus d'une lib que d'un exe (même si on peut l'invoquer en ligne en lui passant tout en paramètre) : pour l'utiliser dans toute ses possibilités, il faut écrire son script de build en Python.
(Même remarque pour Shake-Forward, sauf que la il faut scripter en haskell).
Donc ça confirme que l'on peut faire smk depuis au moins dix ans. Reste la forme, je pense qu'ils ne sont pas sur le même créneau simplicité - universalité.
[^] # Re: seulement pour du C ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 1.
Malheureusement, ça ne marchera pas, car
smkne sait pour l'instant lancer que des commandes. Or, là, c'est du shell…Lancer un shell réglerait ce problème et pas mal d'autres, mais j'hésite à cause des perfs.
[^] # Re: Quid des perfs ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3.
Merci Guillaum, très intéressant, je vais aller voir les références.
Pour ce qui est du problème du build initial, effectivement, convertir un énorme projet à cette approche peut poser problème si le temps total de build est en jours (même si on peut toujours réfléchir à une conversion progressive, en insérant progressivement smk dans les makefiles existants).
Par contre, le stockage de
smkest fait ainsi :pour chaque smkfile, chaque couple sources/cibles est indexé par la ligne de commande. Donc si tu rajoutes une commande, ça rajoute une entrée, et si tu modifies une commande, idem. Il n'y a donc pas a ré-exécuter tout à chaque mise à jour du smkfile, et donc pas de problème pour croître avec le projet.
Il faut juste que j'ajoute dans ma suite un test pour vérifier que le runfile n'enfle pas quand on le fait de façon répétitive avec des lignes de commandes "mortes" qui ne figurent plus dans le smkfile. Je vais m'enregistrer une issue pour penser à traiter ce problème.
[^] # Re: Une amélioration possible
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 1.
Ca rejoint également ce que disait liberf0rce plus haut : utiliser gcc -MM
Je vais potasser ça!
[^] # Re: Une amélioration possible
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 1.
OK, à discuter.
A priori, ce n'est pas dans mon idée de développer un tel mécanisme, je préférerais garder une syntaxe simple, et compatible shell script.
[^] # Re: pourquoi -o machin.o
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 1.
Il n'y a pas vraiment de raison, j'ai juste repris les exemples de ce tuto
Après je pense que c'est plus clair pour comprendre ces histoires de sources et de cibles d'avoir les cibles de façon explicite dans la ligne de commande.
Mais on est bien d'accord que ça ne change rien pour smk, puisque l'outils regarde les fichiers réellement accédés, pas la ligne de commande ni le smkfile.
[^] # Re: Yet another build system
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3.
Hello, pas sur de comprendre ta question le calcul de dépendance, tu parles bien du cas ou l'output d'une commande invalide l'input d'une autre?
Dans ce cas, oui, c'est fait.
L'implémentation est naïve aujourd'hui, car je n'ai pas implémenté de graphe de dépendance.
C'est fait ainsi : je parcours la liste des commandes, si l'une d'entre elle est exécutée, alors je re-parcours toute la liste. Quand plus aucune commande n'est exécutée, je sors.
Pour éviter des cas pathologiques de dépendances récursives, le nombre de boucles est limité au nombre de commande, qui est le max du worst-case.
Pas forcément optimal en terme de perf, mais tellement plus simple à coder dans un premier temps.
Sur le second point, justement l'overhead, pas encore de mesure à ce point. Mais vu que vous êtes plusieurs à poser la question, je ferai un "time" comparatif d'un Makefile et d'un smkfile équivalent
(j'ai créé une issue sur GitHub).
[^] # Re: Quid des perfs ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 5.
Non, et je n'ai pas envie de me lancer dans ces mesures tant que je n'aurai pas les idées claires sur l'intérêt de l'outil, et sur son domaine d'emploi.
Dans mon intention, l'idée principale est de gagner du temps lors de l'écriture / l'automatisation du process.
A première vue, l'exécution est rapide.
Mais peut-être que sur mes cas de tests simple, l'overhead est supérieur au temps d'exécution d'une commande gcc que l'on cherche à éviter, c'est tout à fait possible!!
(en taille de fichier, ça reste négligeable, mais je n'ai pas encore mis dans ma suite de test un gros build avec plein de fichier lu et écrits, type prod de site web).
Bien sûr :-)
Mais mon Makefile est déjà trop complexe. Par exemple, je pipe des commandes les unes dans les autres sur certaines lignes. Et smk ne sait pas lancer de shell, juste des commandes.
Et bien sûr j'utilise des variables, pas encore supportées non plus.
Mais je garde en tête cet objectif, qui est de faire la même chose que mon Makefile, et de voir si j'y arrive vraiment de façon plus simple.
[^] # Re: Quid des perfs ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 6.
Merci!
Oui, c'est amusant dans mon exemple de voir que pour
gcc -o hello.o -c hello.c, il y a 55 fichiers accédés en read, alors qu'un seul nous intéresse, hello.c!D’ou mon choix d'ignorer par défaut les fichiers systèmes dans les affichages, sinon c'était illisible.
(pour voir les fichiers systèmes, il y a une option --shows-all-files)
Par contre, tous les fichiers sont bien pris en compte: si /usr/include/stdio.h est mis à jour, la recompilation sera bien faite.
[^] # Re: Yet another build system
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 3.
oui, on m'a déjà fait des retours de ce type (je crois même que c'est l'issue #1 sur GitHub!).
Je ferai une section "hints", donnant quelques commandes habituelles pour générer les dépendances, c'est toujours intéressant, mais ce sera pour mieux préciser que ce n'est pas la cible de smk.
Je ne prétends pas faire mieux qu'un outil dédié qui recompile ce qui doit l'être (comme gprbuild que j'utilise pour le code de smk), et qui peut même faire une analyse sémantique des sources et ne pas recompiler si par exemple seul les commentaires ont étés modifiés.
L'idée est plutôt d'optimiser des enchaînements de commandes plus simple (le make complexe de compilation pouvant d'ailleurs être une de ces commandes), avec un outil universel (non dépendant de la sémantique de ce qui est construit).
Cela montre l'urgence d'avoir dans ma doc d'autres exemples que du build gcc!
Est-ce que tu vois un intérêt à l'outil pour des choses autres, que tu traiterais par exemple par shell script?
(et merci en tout cas pour le retour)
[^] # Re: Bravo pour le concept et le "hack" de strace !
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 5.
https://github.com/LionelDraghi/smk/issues/14
[^] # Re: Bravo pour le concept et le "hack" de strace !
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 5. Dernière modification le 11 décembre 2018 à 10:19.
Merci Adrien pour ta super appréciation sur l'idée!
Mon intention est de limiter au maximum le travail fait pour être compatible avec un shell file ou un Makefile.
Mais j'ai posté ce journal exactement pour avoir ce genre de retour.
Je suppose que tu fait allusion aux lignes du genre:
Oui, je ne suis pas sûr de pouvoir passer au travers.
J'y ai réfléchi, et la partie substitution de variable n'est pas si compliquée, je créé une entrée dans github pour m'y atteler pendant les vacances de Noël!
[^] # Re: seulement pour du C ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal `smk`, un make sans Makefile. Évalué à 8.
Hello Jean-Baptiste,
la force de l'outils, c'est qu'il est complètement indépendant des commandes exécutées.
Il n'a pas la moindre idée de ce qui est compilé, il ne sait même pas si c'est de la compilation, et c'est tout à fait ce que je veux.
Il fonctionne donc aussi bien avec Fortran qu'avec n'importe quel langage y compris pas encore inventé (sauf à ce que les sources ne soient pas dans des fichiers).
J'ai utilisé un build typique C, mais c'est par facilité parce que c'est ce que l'on trouve dans tout les tutos de make.
En fait, je suis aussi preneur d'autres scripts que vous auriez, pour varier mes exemples et mes tests, comme par exemple la production de sites web, ou de documents, type:
latex <file>.tex
dvips <file>.dvi
ps2pdf <file>.ps
pdf2eps <pagenumber> <file>
[^] # Re: En passant par le chemin de mon SSD
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 2.
En fait, ce n'est pas dans le cas du SSD une optimisation de performance, mais une optimisation de durée de vie.
Ma compréhension est qu'avec l'algo deadline, il y a moins de chance de se trouver dans la situation d'une écriture de bloc, suivie dans la milliseconde de la réécriture du même bloc parce que un second write a été fait sur d'autres octets dans la même zone.
Pour les DD on voulait optimiser le point faible : la mécanique. Pour les SSD on veut réduire les write, mais le principe reste le même, regrouper les écritures par bloc.
Bien sûr, je n'ai aucun moyen de vérifier si cela a un impact réel sur la durée de vie, c'est pourquoi je disais faire confiance (même si ce cas pathologique de réécriture me semble un peu théorique).
Pour ma référence à l'expérimentation à la fin de ce même paragraphe, je pensais à l'algo noop : les premiers tests, qu'il faut prendre avec des pincettes, semble en effet confirmer que cet algo plus simple donne les mêmes performances que les deux autres sur un SSD.
Mais d'un autre côté, sa simplicité n'occasionne pas des gains de CPU substantiels qui à leur tour amélioreraient les performances (ce qui est normal, puisque sur nos PC de bureau, SSD ou pas SSD la CPU n'est toujours pas le maillon faible, l'optimiser dans les coins ne sert donc pas à grand chose).
Après, si quelqu'un veut dérouler le script donné plus haut sur un DD pour voir si ce paramètre change les choses, ce pourrait être intéressant dans les situation mixte DD/SSD car on peut faire un choix d'algo différent par device.
[^] # Re: noatime et deadline
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 1.
Merci pour le truc,je vais essayer.
Pour éviter aux lecteurs de chercher comme je viens de le faire, echo 3 dans ce paramètre free pagecache, dentries and inodes.
Maintenant, le but étant d'évaluer l'impact de certain réglages relatifs au SSD sur les performances dans des conditions réelles, là on s'en éloigne un peu.
Au pire la première compilation sera plus lente que les suivantes, mais quant on code, on en fait en général quelques une à la suite, donc au total l'impact ne devrait pas être marquant.
Le j c'est par réflexe, je ne voulais pas m'en servir dans la boucle.
Mais ton idée d'un -j64 est excellente (quoi que je doute que gcc arrive à en faire autant en // sur ce code pas si gros que ça).
J'essaierai avec ces deux modifs.
[^] # Re: Sauf que...
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 2.
Alors là, tous les deux vous m'avez satellisé!
[^] # Re: plus de RAID ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal Migrer vers un SSD simplement avec lvm. Évalué à 4.
J'ai un rdiff-backup qui tourne tous les soirs sur un DD dédié au backup, donc une panne totale n'aurait pas d'effet catastrophique.
Mais surtout, cela rejoint les considération générales sur la fiabilité des SSD : je pense qu'on a maintenant un recul suffisant (mais je me fait peut-être des idées…) pour supposer que leur fiabilité est supérieure à celle des DD classique, et ce sur une durée raisonnablement longue.
Par ailleurs, j'ai bien regardé les retour d'expérience sur les SSD, et j'ai choisi un beau modèle (pas à un prix plancher), sans problème connu de fiabilité.
Je ne suis donc pas plus inquiet que ça!