Donc, on verra florir des patchs de plus dans les applis du genre if ($encoreUnAutreNavigateur=="ceNavigateur") then bidouille;
C'était surtout vrai à la grande époque de ie6 où le web était un vrai farwest, maintenant il y a des tas de bibliothèques éprouvées qui permettent de s'abstraire du navigateur (jquery en tête, mais aussi https://github.com/es-shims/es5-shim), et les navigateurs font de vrai efforts pour supporter html5.
Ajoute à ça le fait que les navigateurs se mettent maintenant à jour automatiquement (donc un parc d'utilisateur globalement homogène avec des navigateurs récents), au final (sauf besoin client fort bien sûr) tu peux sans remords balancer un message d'erreur et demander à l'utilisateur de mettre à jour son navigateur si il ne support pas ce dont tu as besoin (en plus c'est pour son bien avec toutes les failles de sécurités…).
exemple :
<!--[if lt IE 7]>
You are using an outdated browser. Please upgrade your browser to improve your experience.
<![endif]-->
De la pub pour quoi ?
Pour Heroku (qui est un super service, c'est vrai) ? Je donne des solutions alternatives
Pour appliquer des bonnes pratiques pour rendre ses applications meilleurs ? Assurément !
Pour Docker ? c'est le bon journal non ;-)
Une application c'est parfois un service TCP, un service http + une base de données : 3 containers ou un groupe de 3 ou 1 seul container ?
L'idée de Docker c'est de découper son application en briques de bases, puis de conteneuriser ces briques.
Dans ton cas on a :
- une base de donnée : sur le site de docker son fourni des conteneurs tout prêt pour la plupart des bdd
- un service TCP, un service http : vu que http passe par TCP, je ne suis pas sûr de ce que tu veux dire, mais si il s'agit de deux services différents (un serveur web + un tracker de torrent d'iso linux), tu vas donc créer deux conteneurs docker (en écrivant deux Dockerfile)
Quel sont les applications non dockerisables ?
Tout est potentiellement dockerisable ("quels sont les applications non exécutable dans une vm ?"), toutefois une application dont les composants sont fortement couplés se prêtera beaucoup moins (par exemple si ton application nécessite que ta base de donnée soit en local, ton Dockerfile va se complexifier, et la base de donnée va faire grossir l'image du conteneur qui deviendra difficilement portable avec le temps)
Docker n'est il pas la VM java du siècle dernier ? , en gros va t il réussir la ou java à échoué ?
Où est-ce que java a échoué ? Pas dans le monde des serveurs où il est très présent ! Docker ne sert pas à empaqueter une application client (encore que, certain y pensent comme solution d'isolation, bien que ce ne soit pas au point pour le moment).
Java avais l'avantage de permettre au admin sys de déployer sur un serveur (pouvant être une architecture powerPC, sparc etc…) un binaire compilé par l'équipe de dev (travaillant sur x86), de nos jours les parts de marché de x86/amd64 sont écrasantes (et beaucoup de langages sont interprétés), on est donc en droit de se foutre de la gueule de java tous les vendredi ;-)
Si il y a une chose qui a changé la vie de mes applications web, c'est le passage du iaas (vm amazon "aws ec2") au paas (heroku):
avec aws, on te file une vm et tu installes l'OS, configure le routage, fait les mises à jours, gère les logs etc… C'est lourd au quotidien, mais la galère arrive vraiment quand on commence à vouloir hébergé sa base de donnée avec redondance (et sauvegardes récurentes), à scaller ses serveurs en fonction de la charge
avec Heroku, tu donnes ton code, tu précise ses dépendances et c'est tout ! Toute la maintenance sans rapport avec ton code est sous-traité à un spécialiste, les questions de scalabilité ne sont qu'un curseur à régler (voir rien du tout si on demande une scalabilité automatiquement !), on ne raisonne plus en terme de serveurs mais en terme de services.
La philosophie derrière cette révolution, c'est le concept de l'application aux 12 facteurs (traduction libre, allez voir http://12factor.net/). En respectant ces 12 règles, on obtient une architecture moderne® qui simplifie énormément le cycle de vie des applications.
Le rapport avec Docker ? Heroku utilise son propre système de conteneurisation des applications (le "slug"), Docker permet donc de disposer d'un format standard et open-source d'empaquetage des applications.
Grace à cette technologie le monde du PAAS est en pleine expansion :
- le projet Deis qui vise fournir une stack comme Heroku avec Docker (http://deis.io/)
- Amazon à lancé Beanstalk pour héberger des conteneurs Docker
- Des clouds basés sur docker se lancent à la pelle (premier lien sur google http://www.centurylinklabs.com/top-10-startups-built-on-docker/)
J'imagine qu'à l'avenir on pourra très simplement passer d'un fournisseur de cloud à l'autre (voir héberger son application via plusieurs fournisseurs) grâce à Docker, ce qui favorisera la concurrence (et donc baisse des $$$ ainsi que moindre dépendance aux géants comme Amazon et Google).
Pour en avoir fait pas mal dans un précédent projet, le XLST (en plus de son illisibilité chronique dû à XML) prend vite en complexité dès qu'on utilise des fonctionnalités un peu avancé
- deux versions (v1 et v2) plus ou moins incompatibles et en concurrence
- peu de documentation sur internet et surtout divisé entre v1 et v2 ce qui induit souvent en erreur si la version n'est pas précisé
- la création de fonctions n'est pas intuitive du tout (le fait que ce soit du fonctionnel n'aidant bien sûr pas les gens qui n'y sont pas habitué, soit un bon paquet de programmeurs !)
Bref pour contribuer à du XLST il faut déjà bien le connaître sous peine de passer beaucoup de temps à faire des choses assez triviales, là où Python (qui n'est certes pas très à son avantage ici) est bien plus simple à modifier, même pour un néophyte
Personnellement je me demande pourquoi ils ne sont pas partit sur un moteur de template comme il existe pléthore dans le monde web (au hasard, léger et puissant : http://jinja.pocoo.org/docs/dev/)
J'aurais tout fait en nodejs. Tellement plus facile à installer in fine. De plus je doute qu'aucun de ces composants n'ai pas son équivalent dans npm.
Au contraire je trouve qu'utiliser Docker est une bonne idée pour déployer facilement : un service web peut être développé en ouatmille technos (typiquement ici OPA qui te rebute…) mais cela n'est d'aucun intérêt pour l'utilisateur (comprendre : celui qui va déployer, et qui veut le faire vite sans galérer et sans devoir apprendre un nouvel environnement) qui se focalise légitimement sur ce qui le concerne (i.g. fonctionnalités, performances, stabilité…)
Puisqu'on est dans la couleur, je ne résiste pas à l'envie de partager ma découverte du jour : un petit caviar de mauvaise foie issue du ~/.bashrc de ubuntu/debian par défaut.
# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes
En gros si tu utilises la couleur dans ton prompt, c'est que t'es un n00b frivole !
Mince, moi qui croyait que ça servait à repérer le début d'une commande instantanément quand on navigue dans son historique, à avoir une aide visuelle pour savoir si on est en local ou sur une autre machine en ssh ou encore si on est sur une console root etc…
C'est grâce à ce genre de foutage de gueule qu'on s'est saigné les yeux pendant des décennies sur les sorties de gcc (miam les erreurs de templates C++ hyper-verbeuses en monochrome !) jusqu'à ce que clang arrive et que la vindicte populaire force gcc à s'aligner dessus.
Sur ce coup gloire à dash !
Avec tout le parc ubuntu l'utilisant à la place de bash comme /bin/sh (j'imagine que c'est pareil pour debian), ça exclu quand même un bon nombre de serveur.
Évidemment jusqu'à ce qu'une faille analogue soit trouvée dans dash… à ce moment il nous restera eshell !
Wolfire Games avait libéré le code de Lugaru après son passage sur le Humble Bundle…
Resultat des petits enfoirés malins on fait un portage sur iphone (illégal puisque utilisant les "assets" propriétaires) pour se faire du blé à pas cher !
Quand on pense à la situation précaire de la plupart des indies, c'est sûr que prendre un tel risque pour un bénéfice financier quasi nul tient de l'acte de foi (ou du marketing auprès des barbus linuxiens…)
Les différences visibles à l'œil nu sont assez subjectives, d'où l'utilisation de métriques «mathématiques» pour départager les formats.
Partant du principe que jpeg/WebP sont des formats destinés à un utilisateur final pour une utilisation ne nécessitant pas une grande qualité (autrement on utilise forcement un format sans pertes), je trouve l'argumentation de Google pertinente : une image quasiment similaire pour l'oeil humain, mais 30% plus petite.
Enfin, il est possible d’écrire des fonctions imbriquées (nested functions, fonctions à l’intérieur d’autres fonctions), contrairement au C, C++ ou Java.
Au vu de asm.js, j'ai un peu de mal avec l'argument "trop lent". En fait ça me fait penser aux mecs qui disent que Java est "trop lent"…
D'ailleurs, vu que ce dernier est la solution que tu as choisis pour Newton Adventure, j'aimerais bien que tu développe ton avis sur Javascript.
Personnellement de ce que j'ai fait de dev avec Javascript et j'aurai plutôt tendance à dire que c'est un langage trop permissif ce qui rend le code rapidement très sale si on n'y fait pas attention. Par contre la rapidité de développement et de déploiement est vraiment flagrante comparé à du C++
Tu aurais dû faire un journal pour ce très bon article, c'est moins volatile que le forum !
Personnellement, le projet sur lequel je travail au boulot est très gros (plusieurs milliers de fichiers dont des centaines de makefiles, récursif bien sûr !)
C'est une vrai horreur à faire marcher :
- illisible, des milliers de lignes qui s'appellent dans tous les sens…
- utilisation massive de variables global qui vont rester dans le shell (donc aucune garantie sur l'état
- scripts de nettoyage trop vieux (nettoient pas tout voir plante carrément !)
- lenteur (des dizaines de secondes juste pour vérifier les dépendances)
- Et bien sûr le moindre changement tient de la gageure !
À côté de ça, mon expérience sur les autotools m'a définitivement convaincu que ce remède est pire que le mal :
- extrêmement bordélique (pan ! voila 10 fichiers en plus dans la racine de ton projet…)
- très lent (mention spéciale au configure)
- mal documenté et complexe à utiliser (la semaine dernière j'ai cherché à modifier un script autotools d'un vieux projet… j'ai laissé tombé après 1h de tâtonnement…)
Au final j'en suis arrivé à la conclusion suivante (complètement opposée à la tienne ! ) : La simplicité avant tout !
- Autant que possible : pas de système de build ! De nos jours, combien de projet on vraiment besoin d'être écrit en C/C++ plutôt qu'en Python ?
- Pour les tout petit projets : Makefile tout seul avec grosso modo trois règles toutes simples (build, clean, %.o:%c)
- Pour le reste : CMake (avec Clang et ninja, mais c'est une question de goûts et ça se change en 2s). Un seul fichier de configuration simple et ça roule tout seul !
# Tu sers avec quoi ?
Posté par G.bleu (site web personnel) . En réponse au journal DjangoFloor. Évalué à 2.
uwsgi et gunicorn dans les dépendances c'est pas redondant ?
[^] # Re: Pourquoi pas, tant que ça respecte les standards?
Posté par G.bleu (site web personnel) . En réponse au journal Internet Explorer is about to be bronsonised. Évalué à 1.
C'était surtout vrai à la grande époque de ie6 où le web était un vrai farwest, maintenant il y a des tas de bibliothèques éprouvées qui permettent de s'abstraire du navigateur (jquery en tête, mais aussi https://github.com/es-shims/es5-shim), et les navigateurs font de vrai efforts pour supporter html5.
Ajoute à ça le fait que les navigateurs se mettent maintenant à jour automatiquement (donc un parc d'utilisateur globalement homogène avec des navigateurs récents), au final (sauf besoin client fort bien sûr) tu peux sans remords balancer un message d'erreur et demander à l'utilisateur de mettre à jour son navigateur si il ne support pas ce dont tu as besoin (en plus c'est pour son bien avec toutes les failles de sécurités…).
exemple :
[^] # Re: Tu aimes Heroku ?
Posté par G.bleu (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 2.
Je ne connaissais pas, merci pour l'info !
Ça a l'air assez jeune, tu as des retours d'expérience dessus ?
[^] # Re: Tu aimes Heroku ?
Posté par G.bleu (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 2.
De la pub pour quoi ?
Pour Heroku (qui est un super service, c'est vrai) ? Je donne des solutions alternatives
Pour appliquer des bonnes pratiques pour rendre ses applications meilleurs ? Assurément !
Pour Docker ? c'est le bon journal non ;-)
[^] # Re: Questions de vieux cons
Posté par G.bleu (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 3.
L'idée de Docker c'est de découper son application en briques de bases, puis de conteneuriser ces briques.
Dans ton cas on a :
- une base de donnée : sur le site de docker son fourni des conteneurs tout prêt pour la plupart des bdd
- un service TCP, un service http : vu que http passe par TCP, je ne suis pas sûr de ce que tu veux dire, mais si il s'agit de deux services différents (un serveur web + un tracker de torrent d'iso linux), tu vas donc créer deux conteneurs docker (en écrivant deux Dockerfile)
Tout est potentiellement dockerisable ("quels sont les applications non exécutable dans une vm ?"), toutefois une application dont les composants sont fortement couplés se prêtera beaucoup moins (par exemple si ton application nécessite que ta base de donnée soit en local, ton Dockerfile va se complexifier, et la base de donnée va faire grossir l'image du conteneur qui deviendra difficilement portable avec le temps)
Où est-ce que java a échoué ? Pas dans le monde des serveurs où il est très présent ! Docker ne sert pas à empaqueter une application client (encore que, certain y pensent comme solution d'isolation, bien que ce ne soit pas au point pour le moment).
Java avais l'avantage de permettre au admin sys de déployer sur un serveur (pouvant être une architecture powerPC, sparc etc…) un binaire compilé par l'équipe de dev (travaillant sur x86), de nos jours les parts de marché de x86/amd64 sont écrasantes (et beaucoup de langages sont interprétés), on est donc en droit de se foutre de la gueule de java tous les vendredi ;-)
# Tu aimes Heroku ?
Posté par G.bleu (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 5.
Si il y a une chose qui a changé la vie de mes applications web, c'est le passage du iaas (vm amazon "aws ec2") au paas (heroku):
avec aws, on te file une vm et tu installes l'OS, configure le routage, fait les mises à jours, gère les logs etc… C'est lourd au quotidien, mais la galère arrive vraiment quand on commence à vouloir hébergé sa base de donnée avec redondance (et sauvegardes récurentes), à scaller ses serveurs en fonction de la charge
avec Heroku, tu donnes ton code, tu précise ses dépendances et c'est tout ! Toute la maintenance sans rapport avec ton code est sous-traité à un spécialiste, les questions de scalabilité ne sont qu'un curseur à régler (voir rien du tout si on demande une scalabilité automatiquement !), on ne raisonne plus en terme de serveurs mais en terme de services.
La philosophie derrière cette révolution, c'est le concept de l'application aux 12 facteurs (traduction libre, allez voir http://12factor.net/). En respectant ces 12 règles, on obtient une architecture moderne® qui simplifie énormément le cycle de vie des applications.
Le rapport avec Docker ? Heroku utilise son propre système de conteneurisation des applications (le "slug"), Docker permet donc de disposer d'un format standard et open-source d'empaquetage des applications.
Grace à cette technologie le monde du PAAS est en pleine expansion :
- le projet Deis qui vise fournir une stack comme Heroku avec Docker (http://deis.io/)
- Amazon à lancé Beanstalk pour héberger des conteneurs Docker
- Des clouds basés sur docker se lancent à la pelle (premier lien sur google http://www.centurylinklabs.com/top-10-startups-built-on-docker/)
J'imagine qu'à l'avenir on pourra très simplement passer d'un fournisseur de cloud à l'autre (voir héberger son application via plusieurs fournisseurs) grâce à Docker, ce qui favorisera la concurrence (et donc baisse des $$$ ainsi que moindre dépendance aux géants comme Amazon et Google).
[^] # Re: Je rêve...
Posté par G.bleu (site web personnel) . En réponse au journal Microsoft utiliserait le chantage des brevets Android pour forcer Samsung à diffuser des spywares. Évalué à 10.
Ma fois 2.9%, c'est le genre de part de marché qui me ferait dire que windows phone n'est pas prêt pour le desktop…
[^] # Re: Nuances sur le nettoyage XSLT
Posté par G.bleu (site web personnel) . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 3.
Pour en avoir fait pas mal dans un précédent projet, le XLST (en plus de son illisibilité chronique dû à XML) prend vite en complexité dès qu'on utilise des fonctionnalités un peu avancé
- deux versions (v1 et v2) plus ou moins incompatibles et en concurrence
- peu de documentation sur internet et surtout divisé entre v1 et v2 ce qui induit souvent en erreur si la version n'est pas précisé
- la création de fonctions n'est pas intuitive du tout (le fait que ce soit du fonctionnel n'aidant bien sûr pas les gens qui n'y sont pas habitué, soit un bon paquet de programmeurs !)
Bref pour contribuer à du XLST il faut déjà bien le connaître sous peine de passer beaucoup de temps à faire des choses assez triviales, là où Python (qui n'est certes pas très à son avantage ici) est bien plus simple à modifier, même pour un néophyte
Personnellement je me demande pourquoi ils ne sont pas partit sur un moteur de template comme il existe pléthore dans le monde web (au hasard, léger et puissant : http://jinja.pocoo.org/docs/dev/)
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par G.bleu (site web personnel) . En réponse au journal PEPS : Une nouvelle solution de messagerie (et plus) pour Linux. Évalué à 2.
Au contraire je trouve qu'utiliser Docker est une bonne idée pour déployer facilement : un service web peut être développé en ouatmille technos (typiquement ici OPA qui te rebute…) mais cela n'est d'aucun intérêt pour l'utilisateur (comprendre : celui qui va déployer, et qui veut le faire vite sans galérer et sans devoir apprendre un nouvel environnement) qui se focalise légitimement sur ce qui le concerne (i.g. fonctionnalités, performances, stabilité…)
[^] # Re: Sans commentaire
Posté par G.bleu (site web personnel) . En réponse au message Stage - Développement web Python/AngularJS. Évalué à 1.
C'est plutôt calme niveau candidats, j'imagine que beaucoup d'étudiants ont déjà trouvé leur stage, à moins que ce ne soit l'effet "fêtes de noël"…
# « Si Hemingway écrivait en JavaScript »
Posté par G.bleu (site web personnel) . En réponse au journal « Si Hemingway écrivait en JavaScript ». Évalué à 10.
Ma foi, on tient une piste intéressante sur les causes de son suicide…
# Non à la couleur dans le terminal !
Posté par G.bleu (site web personnel) . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 7.
Puisqu'on est dans la couleur, je ne résiste pas à l'envie de partager ma découverte du jour : un petit caviar de mauvaise foie issue du ~/.bashrc de ubuntu/debian par défaut.
En gros si tu utilises la couleur dans ton prompt, c'est que t'es un n00b frivole !
Mince, moi qui croyait que ça servait à repérer le début d'une commande instantanément quand on navigue dans son historique, à avoir une aide visuelle pour savoir si on est en local ou sur une autre machine en ssh ou encore si on est sur une console root etc…
C'est grâce à ce genre de foutage de gueule qu'on s'est saigné les yeux pendant des décennies sur les sorties de gcc (miam les erreurs de templates C++ hyper-verbeuses en monochrome !) jusqu'à ce que clang arrive et que la vindicte populaire force gcc à s'aligner dessus.
[^] # Re: Adobe Reader pour GNU/Linux
Posté par G.bleu (site web personnel) . En réponse au journal PDF d'un site de l'administration illisible. Évalué à 10.
Oui, mais si il n'a pas de boite aux lettres ? ;-)
[^] # Re: Alternatives
Posté par G.bleu (site web personnel) . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 10.
Sur ce coup gloire à dash !
Avec tout le parc ubuntu l'utilisant à la place de bash comme /bin/sh (j'imagine que c'est pareil pour debian), ça exclu quand même un bon nombre de serveur.
Évidemment jusqu'à ce qu'une faille analogue soit trouvée dans dash… à ce moment il nous restera eshell !
[^] # Re: Ça me met en colère !
Posté par G.bleu (site web personnel) . En réponse au journal Turing est battu. Évalué à 10.
Bien simple : le Figaro titrera "un robot dépasse les légendaires lois de la robotique !" et oliwoude nous fera enfin un bon flim sur le sujet…
[^] # Re: Syntaxe étonnante
Posté par G.bleu (site web personnel) . En réponse au journal C++Now 2014. Évalué à 2.
C'est ennuyeux quand on voit sur quoi pointe ta page perso ;-)….
[^] # Re: Charité
Posté par G.bleu (site web personnel) . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 2.
Mais Bram sait-il faire des merveilles sur sa codebase avec 10.000USD ? ;-)
# Y'en a qui ont essayé...
Posté par G.bleu (site web personnel) . En réponse au journal [bookmark] 2014 ne sera pas l'année du jeu libre. Évalué à 3.
Wolfire Games avait libéré le code de Lugaru après son passage sur le Humble Bundle…
Resultat des petits
enfoirésmalins on fait un portage sur iphone (illégal puisque utilisant les "assets" propriétaires) pour se faire du blé à pas cher !1er lien trouvé sur le sujet via google
Quand on pense à la situation précaire de la plupart des indies, c'est sûr que prendre un tel risque pour un bénéfice financier quasi nul tient de l'acte de foi (ou du marketing auprès des barbus linuxiens…)
[^] # Re: Je retourne la question .....
Posté par G.bleu (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 2.
Partant du principe que jpeg/WebP sont des formats destinés à un utilisateur final pour une utilisation ne nécessitant pas une grande qualité (autrement on utilise forcement un format sans pertes), je trouve l'argumentation de Google pertinente : une image quasiment similaire pour l'oeil humain, mais 30% plus petite.
# Nested functions en C
Posté par G.bleu (site web personnel) . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 0.
C'est faisable en C ! (bien que fortement découragé et non standard…)
http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
# FirefoxOS ?
Posté par G.bleu (site web personnel) . En réponse au sondage Quel système d'exploitation mobile utilisez-vous ?. Évalué à 5.
L'option semble manquer !
Bon ok, je ne l'utilise pas encore : mon Peak+ arrive mi-septembre
Mais quelle joie ce sera de
brûlerdélaisser mon Android à ce moment là ![^] # Re: ça marchera jamais?
Posté par G.bleu (site web personnel) . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 2.
Au vu de asm.js, j'ai un peu de mal avec l'argument "trop lent". En fait ça me fait penser aux mecs qui disent que Java est "trop lent"…
D'ailleurs, vu que ce dernier est la solution que tu as choisis pour Newton Adventure, j'aimerais bien que tu développe ton avis sur Javascript.
Personnellement de ce que j'ai fait de dev avec Javascript et j'aurai plutôt tendance à dire que c'est un langage trop permissif ce qui rend le code rapidement très sale si on n'y fait pas attention. Par contre la rapidité de développement et de déploiement est vraiment flagrante comparé à du C++
[^] # Re: Je maintiens qu'il y a une partie qui n'est pas terrible
Posté par G.bleu (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 2.
Itanium quoi ;-)
[^] # Re: Prédiction de branchement
Posté par G.bleu (site web personnel) . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 3.
Une idée pour le "!!(x)" ?
C'est pour être sûr que ce qui est passé en paramètre est un booléen ? (i.g. !42 == 0, !0 == 1 ==> !!(42) == 1 )
# Sympa !
Posté par G.bleu (site web personnel) . En réponse au message Makefile générique pour les petits projets. Évalué à 6.
Tu aurais dû faire un journal pour ce très bon article, c'est moins volatile que le forum !
Personnellement, le projet sur lequel je travail au boulot est très gros (plusieurs milliers de fichiers dont des centaines de makefiles, récursif bien sûr !)
C'est une vrai horreur à faire marcher :
- illisible, des milliers de lignes qui s'appellent dans tous les sens…
- utilisation massive de variables global qui vont rester dans le shell (donc aucune garantie sur l'état
- scripts de nettoyage trop vieux (nettoient pas tout voir plante carrément !)
- lenteur (des dizaines de secondes juste pour vérifier les dépendances)
- Et bien sûr le moindre changement tient de la gageure !
À côté de ça, mon expérience sur les autotools m'a définitivement convaincu que ce remède est pire que le mal :
- extrêmement bordélique (pan ! voila 10 fichiers en plus dans la racine de ton projet…)
- très lent (mention spéciale au configure)
- mal documenté et complexe à utiliser (la semaine dernière j'ai cherché à modifier un script autotools d'un vieux projet… j'ai laissé tombé après 1h de tâtonnement…)
Au final j'en suis arrivé à la conclusion suivante (complètement opposée à la tienne ! ) : La simplicité avant tout !
- Autant que possible : pas de système de build ! De nos jours, combien de projet on vraiment besoin d'être écrit en C/C++ plutôt qu'en Python ?
- Pour les tout petit projets : Makefile tout seul avec grosso modo trois règles toutes simples (build, clean, %.o:%c)
- Pour le reste : CMake (avec Clang et ninja, mais c'est une question de goûts et ça se change en 2s). Un seul fichier de configuration simple et ça roule tout seul !