Redo, un remplaçant de choix pour Make

Posté par (page perso) . Modéré par Xavier Teyssier.
Tags :
19
16
jan.
2011
Ligne de commande
Make est l'outil le plus couramment utilisé pour automatiser la production d'un fichier à partir de règles. L'exemple typique est la compilation d'un logiciel à partir de ses sources. Mais Make a des inconvénients de taille, dont :
  1. La syntaxe sujette aux erreurs ;
  2. Les appels récursifs à make posent problème ;
  3. Le manque de modularité ;
  4. L'absence d'atomicité de l'application des règles.

Daniel J. Bernstein, l'auteur de qmail et djbdns, a proposé une alternative à Make qu'il a appelée redo, mais celle-ci se présente sous forme de notes et non pas de code.

Avery Pennarun a trouvé ses notes et en a écrit une version en Python sous licence LGPL.

Redo fonctionne avec des scripts shell avec l'extension .do et chacun de ces fichiers décrit une règle. Par exemple, le fichier default.o.do qui servirait à générer des fichiers .o à partir des sources .c correspondantes s'écrirait de cette façon :
redo-ifchange $1.c

gcc -MD -MF $3.deps.tmp -c -o $3 $1.c
DEPS=$(sed -e "s/^$3://" -e 's/\\//g' <$3.deps.tmp)
rm -f $3.deps.tmp
redo-ifchange $DEPS
Note : $1 est le nom du fichier cible sans l'extension et $3 le nom du fichier temporaire qui deviendra le fichier cible ($3 sera renommé à la fin de la règle, évitant ainsi de laisser un fichier cible corrompu si quelque chose devait mal se passer). redo-ifchange est une commande servant à déclarer une dépendance.
  • # Ant ?

    Posté par . Évalué à 1.

    Redo, un remplaçant de choix pour Make

    Personnellement ,si il y a un programme qui pourrait remplacer Make , c'est Ant à mon avis.

    Déjà par l'antériorité mais aussi par la souplesse de cette outil qui est presque sans limite.

    La bibliotheque de "task" est déjà énorme et te permet de scripter n'importe quoi et surtout réellement multi-plateforme.

    Enfin ,tu peux créer très simplement des "Task" maison et les intégrés des scripts Ant.

    http://ant.apache.org/manual/tasksoverview.html
    • [^] # Re: Ant ?

      Posté par (page perso) . Évalué à 10.

      Il faut quand même se farcir la JVM qui va avec. Et comme il n'est pas prévu avant longtemps d'accélérer le démarrage de cette JVM, ça ne risque pas de vraiment sortir des projets Java, surtout s'il des concurrents comme Redo qui n'ont pas besoin de la JVM.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Ant ?

        Posté par . Évalué à 10.

        Et il faut se farcir son xml aussi.

        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: Ant ?

          Posté par (page perso) . Évalué à 10.

          faut se farcir

          Le XML, c'est comme la violence : si ça marche pas, c'est qu'il n'y en a pas assez.

          * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Comparaison du chargement d'une VM python et chargement d'une VM Java

        Posté par . Évalué à 2.

        syj@syj-laptop:~/todelete$ cat main.java
        class Main {
        public static void main(String[] args) {
        System.out.println("Hello the world");
        }
        }
        syj@syj-laptop:~/todelete$ cat hello.py
        print "Hello the world


        syj@jsyj-laptop:~/todelete$ time java Main
        Hello the world

        real 0m0.070s
        user 0m0.028s
        sys 0m0.036s

        syj@syj-laptop:~/todelete$ time python hello.py
        Hello the world

        real 0m0.023s
        user 0m0.016s
        sys 0m0.008s
      • [^] # Re: Ant ?

        Posté par . Évalué à 4.

        Un peu de sérieux les gens. Depuis le temps que je traîne par ici, vous m'avez forcé à ouvrir un compte.
        Ant je veux bien, mais utiliser java pour la compilation, ça a de sérieux inconvénients en contre partie de sa portabilité pour une utilisation par défaut.
        Vous voyez java dans une stage 3 de gentoo ? Je ne parle même pas de LFS… Sans compter qu'une JVM c'est quand même lourd (sans troller) et tout le monde n'en veut pas sur son système. Et que dire de l'ombre d'oracle qui plane derrière java ? (ah zut on est lundi ?)
    • [^] # Re: Ant ?

      Posté par . Évalué à 2.

      La dernière fois que j'ai utilisé Ant, j'avais un lien symbolique vers un dossier contenant des fichiers nécessaires au programme dans le dossier de build. En lançant "ant clean", cet abruti, plutôt que d'effacer le lien symbolique, a récursivement effacé le contenu de la cible... Bon heureusement tout était versionné je n'ai rien perdu, mais ça donne pas envie de poursuivre avec ant.

      Et les fichiers XML de 50000 lignes c'est à se flinguer.
      • [^] # Re: Ant ?

        Posté par (page perso) . Évalué à 0.

        Mouais... Entre un fichier XML lisible avec des balises intelligibles et un Makefile abscons bourré de commandes je sais pas lequel est le pire
        • [^] # Re: Ant ?

          Posté par . Évalué à 6.

          dest: src1 src2
          \tcmd1
          \tcmd2

          C'est tout de même vachement simple comme syntaxe. Après les commandes, c'est pas lié à make, mais à ce que tu veut faire.

          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

          • [^] # Re: Ant ?

            Posté par (page perso) . Évalué à 0.

            La syntaxe des Makefile simple ? Déjà, il ne faut pas confondre les espaces et les tabulations. Puis, il vaut mieux ne pas avoir de fichiers dont le nom contienne une espace. Et plus généralement, la syntaxe est simple sur les cas de bases mais peut vite devenir horrible sur des cas particuliers.
            • [^] # Re: Ant ?

              Posté par . Évalué à 7.

              Cette histoire d'espace et de tabulation ....
              Faut le savoir c'est simple, oui c'est une limitation à la noix, mais c'est trivial à utiliser, vérifier.

              Les bons IDE, permettent à ceux qui font de l'expendtab (comme moi) de ne pas le faire pour les fichiers [mM]akefile.

              Les nom de fichiers sans espaces je considère que c'est une bonne pratique générale en informatique.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: Ant ?

                Posté par . Évalué à 1.

                Les nom de fichiers sans espaces je considère que c'est une bonne pratique générale en informatique.

                Moi aussi, par confort, mais faut quand même reconnaître que c'est une limitation stupide avec laquelle il faut composer. Si on va par là, on peut limiter les noms des fichiers à 8 caractères et une extension en trois lettres.
                • [^] # Re: Ant ?

                  Posté par . Évalué à 4.

                  De l'autre manière c'est un peu comme dire que la limitation à 80 colonnes est obsolète et qu'avec mon écran large 22", je pourrais facilement la monter à 240 sans problème.

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                  • [^] # Re: Ant ?

                    Posté par . Évalué à 2.

                    Ce qui est le cas...

                    Bon OK ça permet de mettre deux fichiers cote à cote ce qui est pratique quand on fait un diff ou autre, mais 80 caractères je trouve ça trop court, se limiter à 100 ou 120 m'éviterait souvent de devoir passer à la ligne juste pour ça.

                    Après pour les gens qui codent en C et qui suivent la tradition d'avoir des noms de fonctions/variables les plus courts et cryptiques qui soient (genre appeler la moitié de ses variables "buf") c'est peut-être trop long, comme pour les dev C#/Java qui font quasiment des phrases en CamelCase c'est peut-être trop court, mais en tout cas on devrait définir cette limite selon les besoins d'aujourd'hui plus que selon la largeur des terminaux d'il y a 30 ans.
                    • [^] # Re: Ant ?

                      Posté par . Évalué à 6.

                      Le problème c'est que le cerveau humain n'a pas beaucoup évoluer ces 20 dernière années.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Ant ?

      Posté par (page perso) . Évalué à 3.

      Une des choses que je n'aime pas chez Make est justement le côté trop script shell et pas plus haut niveau, avec comme problèmes :
      - le manque d'indépendance de la plateforme
      - les choses horribles du genre de la ligne DEPS donnée en exemple
      Problèmes qui sont résolus par ant, mais pas par le Repo apparemment.
      Cela dit, je reconnais que je n'ai utilisé ant que pour des projets java et que je n'ai pas d'avis sur son adaptation pour d'autres langages.

      À mon avis avec Make on est typiquement dans la situation où on a :
      - un outil historique que tout le monde sait utiliser mais qui a plein de défauts (make)
      - beaucoup d'outils plus modernes n'ayant pas ces défauts (ant et tous les autres), mais du fait de leur multitude, aucun de s'impose vraiment et la seule référence que tout le monde continue à utiliser car dénominateur commun est le logiciel historique
      • [^] # Re: Ant ?

        Posté par . Évalué à 3.

        Pour java, personnellement j'utilise un outil encore plus haut niveau que ant : maven.

        J'ai vraiment pas envie de me farcir un build.xml, mais rien que dans le monde Java il y a une multitude de builder : buildr, Ivy, Grape,...

        Je ne les ai pas essayé parce que je suis très bien avec maven.

        Pour make, je n'ai pas encore trouvé de remplaçant qui me satisfasse (quelque chose de vraiment indépendant d'un langage, qui soit simple, flexible). Le seul qui pourrait peut être le remplacer c'est omake, qui est plutôt une évolution de make.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: Ant ?

          Posté par (page perso) . Évalué à 2.

          Omake à ça de bien qu'il peut lancer une compilation dès que tu modifies un fichier, en sondant (poll) le système de fichier.

          Et si je l'utilise pour quelques projets en LaTeX, j'avoue que j'en suis quand même pas fan. Surtout que la manière dont il analyse les fichiers est obscure (il est supposé ne pas recompiler si tu ne changes que les commentaires par exemple), et qu'il ignorait dans mon cas la bibliographie de mon projet, refusant d'appeler bibtex tant que le nom de fichier n'était pas le même que celui du fichier tex principal…
          • [^] # Re: Ant ?

            Posté par (page perso) . Évalué à 1.

            Un système trop intelligent ne sera pas assez généraliste et sera pénible car il y a une multitude de langage et des nouveaux langages arrivent...

            Il me semble qu'il y a deux systèmes simples pour voir si un fichier a été modifié, la date et un checksum. Tout autre système devient intrusif. Il faudrait pouvoir choisir selon le type de fichier. C'est un peu ce que propose cfengine dans ses règles de "copy".
  • # scons ?

    Posté par (page perso) . Évalué à 10.

    Redo, un remplaçant de choix pour Make

    Personnellement ,si il y a un programme qui pourrait remplacer Make , c'est SCons à mon avis. (ou waf)

    En tout cas, ça m'étonnerait que l'exemple donné dans la news puisse convaincre une personne de quitter make pour redo ! La lisibilité et la concision du truc est pour le moins pas très impresionnante.
    • [^] # Re: scons ?

      Posté par (page perso) . Évalué à 4.

      Ou CMake.

      CMake, et sans doute SCons et Waf aussi (mais je n'en suis pas sûr) ¹, sont des générateurs de Makefile, et donc make est quand même utilisé par après.
      Donc ces outils ne se situent pas au niveau de make, mais des autohell autotools.

      Si les remplaçants de make commencent à devenir populaire, on pourrait imaginer que CMake et compagnie supportent plusieurs « make-like » en sortie.

      ¹ Pour moi SCons et Waf sont des alternatives à CMake et aux autotools, pas à make.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: scons ?

        Posté par (page perso) . Évalué à 5.

        Tu te trompes. Scons ne génère pas de Makefile. Ou peut-être sur demande, mais ce n'est pas son comportement par défaut. Il s'agit bien d'un alternative à Make.
        • [^] # Re: scons ?

          Posté par (page perso) . Évalué à 2.

          OK.

          Mais il me semble que SCons et Waf offrent plus ou moins le même genre de fonctionnalités que CMake, dont notamment le fait de vérifier si la compilation est possible et de paramétrer cette compilation (suivant le système et les choix de l'utilisateur), ce que ne permettent pas directement make ou redo.

          « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

          • [^] # Re: scons ?

            Posté par (page perso) . Évalué à 1.

            http://www.scons.org/wiki/SconsVsOtherBuildTools

            Ça confirme bien ce que je dis.

            « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

          • [^] # Re: scons ?

            Posté par . Évalué à 2.

            « de vérifier si la compilation est possible et de paramétrer cette compilation (suivant le système et les choix de l'utilisateur), ce que ne permettent pas directement make ou redo »

            Make répond à ces fonctionnalités! Si il manque un fichier ou une « target », make le remonte ; d'autre part il est possible de choisir les actions a effectuer en fonction de variables dépendantes du système ou de la ligne de commande. Je ne vois pas vraiment où tu veux en venir avec cette définition... tu as un exemple précis?
    • [^] # Re: scons ?

      Posté par . Évalué à 3.

      Scons est à la fois un moteur de production comme GNU Make et un système de production de haut-niveau comme autotools ou CMake qui gère les dépendances, la portabilité etc ...

      Par rapport à CMake, il a l'avantage de reposer sur un langage de script complet et flexible (Python/ersatz utilisé par CMake), de former un ensemble cohérent (CMake est un générateur de projets) mais il a un défaut majeur par rapport à GNU Make, il gère horriblement mal la parallélisation des tâches.
      Waf me semble plus à même dans la même catégorie de rivaliser avec Make, il gère mieux la parallélisation (donc nettement plus rapide), une API plus familière aux Pythonistas et une configuration plus souple. Le projet est plus dynamique que Scons, mais un peu brouillon (beaucoup de changement d'APIs)

      Personnellement, même si je préfère l'approche Scons/Waf, j'ai fait le choix de CMake pour les raisons suivantes principalement pour le fait qu'il soit self-contained, très rapide (le jour et la nuit par rapport à Scons), et qu'il dispose d'une large collection de modules pas loin de rivaliser avec autotools. Certes, CMake a un langage de script pourri (mais simple), certes, c'est un générateur de projets mais GNU Make est un composant éprouvé, CMake suppléant à ses défauts, ça en fait une solution tout à fait acceptable dans un cadre industriel ou libre.
      • [^] # Re: scons ?

        Posté par (page perso) . Évalué à 4.

        > par rapport à GNU Make, il gère horriblement mal la parallélisation des tâches.

        Ah ? c'est la premiere fois que j'entends dire ça, perso quand je fais un scons -j4 sur un quad-core il n'a aucun probleme pour faire bosser les 4 coeurs à 100%. La vitesse est effectivement un souci sur les scripts un peu gros, mais par contre il garantie à 100% d'avoir un build correct.

        Sinon une killer feature de scons je trouve, c'est le cache des resultats intermediaires de compilation, ça remplace ccache et c'est plus général.
      • [^] # Re: scons ?

        Posté par . Évalué à 2.

        Il doit bien être possible d'intégrer à CMake un nouveau type de builder en sortie (scons par exemple), non ?

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: scons ?

          Posté par . Évalué à 4.

          Même si ça fait un peu doublon sur certains aspects, c'est tout à fait possible.
          Par contre, les générateurs constituent un cas particulier, il vaut mieux les développer en C++ (typiquement, une classe qui hérite de cmGlobalGenerator), sinon, ce n'est pas maintenable à long terme. C'est pas bien compliqué, CMake est très architecturé et le code source extrêmement bien documenté (tu peux générer une doc doxygen de l'API relativement à jour).

          Le seul point négatif de CMake est son langage de script pourrave, ajouter un nouveau langage, le support d'une bibliothèque est super simple parce qu'on dispose déjà des commandes qui vont bien. C'est pas forcément le cas pour écrire un générateur.
          • [^] # Re: scons ?

            Posté par (page perso) . Évalué à 1.

            Pour la syntaxe de CMake le seul truc qui m'ennuie c'est qu'il faut répéter dans le end la même chose que dans le if ou autre, par exemple :

            if (blabla)
            endif (blabla)

            À part ça je trouve que ça va.

            « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

            • [^] # Re: scons ?

              Posté par . Évalué à 2.

              Depuis la version 2.6, ce n'est plus nécessaire et il existe une variable spéciale pour l'activer sur CMake 2.4.x.
              • [^] # Re: scons ?

                Posté par (page perso) . Évalué à 1.

                Cool c'est bon à savoir.
                Mais alors que reproches-tu à la syntaxe de CMake ?

                « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

                • [^] # Re: scons ?

                  Posté par . Évalué à 2.

                  Les structures de données sont limités, pas de sûreté de type (tout est stocké dans une chaine, les listes sont des chaines séparés par un ";" ce qui n'est pas sans poser problème), la syntaxe est parfois boiteuse (définir une fonction par exemple).

                  Certes, pour un DSL, c'est pas trop mal foutu mais parfois un langage plus évolué (python, lua ou même javascript) faciliterait bien la vie des développeurs.
  • # J'aimerais des explications sur

    Posté par . Évalué à 9.

    La syntaxe sujette aux erreurs ;

    Je trouve que la syntaxe de make plutot claire (je ne parle pas des extensions GNU que j'évite d'utiliser pour rester portable).

    sinon, devoir installer Python pour compiler un pauvre programme C ... euh ... Jen e sais pas pourquoi mais ça me gène.
    • [^] # J'aimerais des explications sur

      Posté par . Évalué à -2.

      Ah j'oubliais : en Ruby ça existe déjà ce truc et ça s'appelle rake. Les pythonneux sont encore en retard d'un train.
      • [^] # Re: J'aimerais des explications sur

        Posté par . Évalué à 4.

        Votre premier message dit "c'est nul d'avoir besoin d'un autre langage pour compiler du C", et votre deuxième message : "c'est bien, on peut utiliser ruby pour compiler du C"...
        • [^] # Re: J'aimerais des explications sur

          Posté par . Évalué à 5.

          Dans le second message il dit juste que Ruby le fait déjà.
          • [^] # Re: J'aimerais des explications sur

            Posté par . Évalué à 2.

            Ce qui n'apporte rien, puisqu'il juge qu'il ne faut pas utiliser d'autres langages pour compiler du C.
            • [^] # Re: J'aimerais des explications sur

              Posté par . Évalué à 3.

              Je crois qu'il fait simplement une tentative de troll python vs ruby.
              • [^] # Re: J'aimerais des explications sur

                Posté par . Évalué à 3.

                Ca fait deux qui suivent. D'ailleurs, la séparation des deux messages n'est pas innocente : je ne tiens pas à parasiter les arguments trollifère des autres.
                • [^] # Re: J'aimerais des explications sur

                  Posté par . Évalué à 3.

                  LinuxFR a le moinssage pour cacher les trolls, mais la contre-attaque facile est de disperser ses trolls dans de nombreux messages.
                  J'avais lu qu'on ne pouvait moinsser une personne que 2 fois par jour, mais templeet n'est pas propice à la vérification de cette information. Pensez-vous que templeet serait plus adapté pour écrire des Makefiles ?
            • [^] # Re: J'aimerais des explications sur

              Posté par (page perso) . Évalué à 2.

              Si, puisque sa phrase peut-être générique en remplaçant C par n'importe quel autre langage (sauf Python évidemment). Après, il donne un exemple avec Ruby quand on fait du Ruby et qui n'avait pas d'équivalent en Python.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: J'aimerais des explications sur

          Posté par . Évalué à 5.

          Votre premier message dit "c'est nul d'avoir besoin d'un autre langage pour compiler du C"
          Pas exactement : plutot "nul besoin d'une usine à gaz comme Python (ou Java, ou Ruby, ou n'importe quel langage "bloatware") pour développer en C.

          t votre deuxième message : "c'est bien, on peut utiliser ruby pour compiler du C"...
          No, je dis qu'un remplaçant à Make pour Ruby existe déjà. Mais je ne m'en servirais pas pour écrire un programme C (j'aime pas multiplier inutilement les dépendances). Par contre ça peut être utile si on veut intégrer du C à un prog. Ruby (ou vice-versa, et vous pouvez remplacer Ruby par Python avec l'outil adéquat).

          L'avantage de Make c'est qu'il est dispo sur tous les Unix dignes de ce nom.
      • [^] # Re: J'aimerais des explications sur

        Posté par (page perso) . Évalué à 1.

        > Les pythonneux sont encore en retard d'un train.

        Ça existait aussi déjà en python, ça s'appelle scons !
        Morale 1 : Si ça existe en ruby, ça existait avant en python et inversement...
        Morale 2 : Les pythonneux ne suivent pas la devise de python : "il n'y a qu'une bonne façon de faire les choses".
        • [^] # Re: J'aimerais des explications sur

          Posté par . Évalué à 2.

          > Morale 2 : Les pythonneux ne suivent pas la devise de python : "il n'y a qu'une bonne façon de faire les choses".
          Mais si, Ruby est la _mauvaise_ façon de faire les choses. Donc pas de conflit avec la règle.
    • [^] # Re: J'aimerais des explications sur

      Posté par (page perso) . Évalué à 5.

      Et alors, bash + m4 + make ça fait 3 langages en plus, alors que si tu fais tout en python ça ne fait qu'un langage en plus...
      • [^] # Re: J'aimerais des explications sur

        Posté par . Évalué à 2.

        comparer un truc simple comme Make, qui est nativement disponible sur tous les Unix et un trc commme python, avec un tas de libs que si tu ne les installe pas t fais pas grand chose avec, c'est euh ... Non rien. Après on s'étonne qu'un pauvre petit logiciel style Hello World nécessite 3 Gb de dépendances pour être compilé et/ou exécuté.
        • [^] # Re: J'aimerais des explications sur

          Posté par (page perso) . Évalué à 2.

          c'est quoi "nativement disponible" sous unix ?
          • [^] # Re: J'aimerais des explications sur

            Posté par . Évalué à 7.

            inclus dans la norme Posix ça devrait suffire pour considérer que c'est nativement disponible sous *nix ?
          • [^] # Re: J'aimerais des explications sur

            Posté par . Évalué à 2.

            Cas 1
            - j'installe l'OS
            - je lance la commande => pouf,pouf, ça marche sans rien installer d'autre.

            à la limite, cas 2:
            -j'installe l'os (version minimale"
            -je lance la commande => PAF ca marche pas.
            - j'installe 1 paquet make
            - je lance =>pouf ça marche.
            • [^] # Re: J'aimerais des explications sur

              Posté par (page perso) . Évalué à 2.

              j'imagine que tu ranges python dans la catégorie 1
              • [^] # Re: J'aimerais des explications sur

                Posté par . Évalué à 3.

                Non. Par bonheur, python est loin d'être installé d'office sur les unix dignes de ce nom.
                • [^] # Re: J'aimerais des explications sur

                  Posté par (page perso) . Évalué à 2.

                  Et sous quel Unix Python n'est pas disponible en paquet, comme make ?
                  • [^] # Re: J'aimerais des explications sur

                    Posté par . Évalué à 0.

                    au hasard Solaris 10
                    • [^] # Re: J'aimerais des explications sur

                      Posté par . Évalué à 3.

                      mouais faux :

                      depuis l'arborescence du dvd d'install de Solaris 10 :

                      # pkginfo -d . | grep -i python
                      GNOME2 SUNWPython The Python interpreter, libraries and utilities
                      GNOME2 SUNWPython-devel The Python interpreter, libraries and utilities - development files
                      GNOME2 SUNWPython-share The Python interperer, libraries and utilities - platform independent files

                      Bon cela-dit, je ne vois pas trop ce qu'il vient faire dans le cluster de packages "GNOME2", qui est effectivement, rarement installé par les admins par défaut.
                      • [^] # Re: J'aimerais des explications sur

                        Posté par . Évalué à 4.

                        Le gestionnaire de paquets lui-même utilise Python, donc Python est installé par défaut :

                        $ head /usr/bin/pkg
                        #!/usr/bin/python2.6
                        #
                        # CDDL HEADER START
                        #
                        # The contents of this file are subject to the terms of the
                        # Common Development and Distribution License (the "License").
                        # You may not use this file except in compliance with the License.
                        #
                        # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
                        # or http://www.opensolaris.org/os/licensing.
        • [^] # Re: J'aimerais des explications sur

          Posté par . Évalué à 10.

          make, bash et leurs potes sont l'exemple typique de trucs simples au départ qui se sont transformés en usine à gaz monstrueuses précisément parce que le principe était de faire simple au départ. Résultat : design merdique et rudimentaire, accumulation de couches de hacks foireux (dis bonjour à ton ami autotools) pour répondre à des besoins de plus en plus sophistiqués.

          Voici le manuel d'un "truc simple comme Make", auquel il est de rigueur d'ajouter le manuel d'un "truc simple comme bash" et celui d'un "truc simple comme autotools". Tant qu'à se farcir une doc aussi touffue et un système aussi complexe, autant apprendre un langage de programmation généraliste qui te servira à autre chose qu'à compiler d'autres programmes. Enjoy.
          http://www.gnu.org/software/make/manual/make.html

          Après on s'étonne qu'un pauvre petit logiciel style Hello World nécessite 3 Gb de dépendances pour être compilé et/ou exécuté.

          En même temps je sais pas pour toi, mais je n'ai pas acheté un ordinateur pour exécuter des Hello World. Sinon un vieil Amstrad CPC te suffira.
    • [^] # Re: J'aimerais des explications sur

      Posté par (page perso) . Évalué à 3.

      > sinon, devoir installer Python pour compiler un pauvre programme C ... euh ... Jen e sais pas pourquoi mais ça me gène.

      La version actuelle de redo est en python, mais son auteur indique qu'à terme, il compte bien le réécrire en C.
      • [^] # Re: J'aimerais des explications sur

        Posté par (page perso) . Évalué à 0.

        >> mais son auteur indique qu'à terme, il compte bien le réécrire en C.

        Pourquoi ? Il veut rajouter des bugs pour gagner un semblant de portabilité et deux micro-pouillèmes de secondes lors de la compilation de projets de 1000 fichiers ?

        Encore un UUOC (Useless Use Of C)…
    • [^] # Re: J'aimerais des explications sur

      Posté par (page perso) . Évalué à 3.

      je ne parle pas des extensions GNU

      Même sans aller jusque là, construire un makefile qui marche sur juste linux-86 et openbsd-sparc64, c'est parfois un peu rude... surtout à 11h du soir...

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: J'aimerais des explications sur

        Posté par . Évalué à 8.

        Un geek c'est efficace à partir de 11h du soir

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Améliorer make

    Posté par (page perso) . Évalué à 4.

    La syntaxe de make n'est peut-être pas extraordinaire mais elle n'est pas bien compliquée non plus.
    Le problème que l'on rencontre le plus souvent est la tabulation obligatoire remplacée par des espaces. J'ai vu un sous-traitant passer deux semaines sur cette erreur avant que je le dépanne.

    Une suggestion serait d'améliorer la détection et les messages d'erreur de make ou de faire un programme de vérification à la façon du validator du W3C ou de nsgmls.
    • [^] # Re: Améliorer make

      Posté par . Évalué à 3.

      Vu ce qu'est capable de faire l'interpréteur de python. Je pense que cette limitation est obsolète.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # CMake ?

    Posté par . Évalué à 5.

    Redo, un remplaçant de choix pour Make

    Personnellement, si il y a un programme qui pourrait remplacer Make , c'est CMake à mon avis.

    La syntaxe est facile à appréhender, il est utilisé pour de très larges projets (KDE entre autres, qui avait hésité à utiliser SCons http://lwn.net/Articles/188693/ ), est multiplateforme, intègre de nombreuses interfaces vers des systèmes de compilation spécifiques à certaines bibliothèques, par exemple des projets basés sur Qt...
    • [^] # Re: CMake ?

      Posté par . Évalué à 9.

      Pas vraiment, le but de CMake est de générer des Makefile
      CMake remplace plutôt les autotools
      • [^] # Re: CMake ?

        Posté par (page perso) . Évalué à 7.

        [quote]
        Pas vraiment, le but de CMake est de générer des Makefile
        CMake remplace plutôt les autotools
        [/quote]

        L'objectif de CMake n'est pas de générer des Makefile, mais un projet de compilation. Pour les habitués de la ligne de commande, cela génère effectivement des Makefile, mais il est également possible de générer des projets pour des IDE comme KDevelop ou Eclipse, et même Visual Studio me semble-t-il.

        Par contre, il est vrai que CMake ne gère pas de compilation par lui-même. Il se contente de se reposer sur des outils déjà existants.
        • [^] # Re: CMake ?

          Posté par . Évalué à 2.

          Ayant dû choisir une système de compilation pour créer des bibliothèques C/C++, on a évalué CMake et les autotools. On est resté aux autotools finalement. Ça m'a sidéré qu'un truc récent comme CMake n'était pas capable de gérer correctement par défaut les compilations statiques/dynamiques (la liste de lib est la même dans les deux cas !). D'ailleurs, si quelqu'un sait comment faire générer à CMake un fichier bibliotheque.pc dont le contenu dépend de ce qu'a trouvé CMake, ça m'intéresse grandement.

          Make/autotools est un outil complexe à prendre en main (si on s'écarte des cas de base) mais il est assez puissant pour faire à peu près tout ce qu'on veut. Après, c'est comme partout : on peut écrire du code propre ou pas (je parle du code Makefile et m4).
          • [^] # Re: CMake ?

            Posté par . Évalué à 3.

            http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:(...)

            puis :

            configure_file(biblio.pc.in biblio.pc)

            De rien :)
            • [^] # Re: CMake ?

              Posté par . Évalué à 1.

              Si c'était ça que je cherchais, je l'aurai trouvé il y a longtemps.
              Ce que je cherche à faire, c'est de faire calculer à CMake ce qu'il faudra dans le biblio.pc en fonction des bibliothèques trouvées sur le système (avec un .pc ou directement avec les flags -l.. -L.., -I...) et en fonction de la façon dont je l'utiliserai (CMake ne peut pas savoir si, en créant ma bibliothèque, il doit mettre les bibliothèques dans la partie private (ie nécessaire uniquement pour le link static) ou public (nécessaire dans tous les cas) donc, si, dans la solution proposée, je n'ai pas à fournir cette info, c'est que ce n'est pas ce que je cherche).

              Pour les autotools, j'ai fait ça :
              http://git.ligforge.imag.fr/?p=users/vdanjean/tools/autolibs(...)
              Pour CMake, je ne vois pas comment faire si on veut garder les routines existantes de CMake pour la détection des bibliothèques (et si on les remplace, ça n'a aucun intérêt par rapport aux autotools)
              • [^] # Re: CMake ?

                Posté par . Évalué à 2.

                Je ne comprends pas bien. Tu peux très bien t'en sortir avec FindPkgConfig [1], et pour les libs qui ne fournissent pas de .pc, avec find_file et find_library. Je pense qu'il y a même moyen d'automatiser certains trucs avec des petites fonctions. Ou alors, je ne comprends pas ce que fait ton script.

                En fait, je me demande s'il n'y aurait pas une négation en trop dans "si, dans la solution proposée, je n'ai pas à fournir cette info, c'est que ce n'est pas ce que je cherche" ? Si c'est le cas, je ne vois pas en quoi ton script y répond. Si ce n'est pas le cas, alors CMake peut le faire aussi.

                [1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:F(...)
              • [^] # Re: CMake ?

                Posté par (page perso) . Évalué à 3.

                Ce que je cherche à faire, c'est de faire calculer à CMake ce qu'il faudra dans le biblio.pc en fonction des bibliothèques trouvées sur le système (avec un .pc ou directement avec les flags -l.. -L.., -I...)

                En pratique, se baser sur ce qu'on peut trouver sur une machine est rarement une bonne idée :

                . ça empêche la compilation croisée, ou du moins la compilation sur une machine rapide pour une utilisation sur une cible différente ;

                . les empaqueteurs des autres systèmes ou distributions vont de toutes façons virer tout ça, pour compiler dans un caisson le plus étanche possible.

                Ce qu'il faut c'est avant tout que l'auteur spécifie correctement les dépendances dont il a besoin en fonction des options choisies, et que le répertoire où celles-ci sont installées soit paramétrable.
          • [^] # Re: CMake ?

            Posté par . Évalué à 2.

            Ça m'a sidéré qu'un truc récent comme CMake n'était pas capable de gérer correctement par défaut les compilations statiques/dynamiques (la liste de lib est la même dans les deux cas !).
            C'est clair que moi aussi j'ai été dessus par CMake.
            Des que tu veux faire un truc un peu complexe on peut tomber sur un cratère (ie c'est pas possible).

            Quand aux autotools c'est une utsine a gaz qui produit des trucs imbitable. Leur configure pour des raison de portabilité est très moche.
            Les Makefile générer ne sont pas mieux.
            Et pour couronner le tout plein de gens font des trucs louche avec autotools.
            • [^] # Re: CMake ?

              Posté par . Évalué à 3.

              > Leur configure pour des raison de portabilité est très moche.
              En plus de ne pas être portable. Par exemple, recompiler libical sous MacOS X nécessite de modifier le configure à la main, malgré qu’il soit généré par autohell.
        • [^] # Re: CMake ?

          Posté par . Évalué à 4.

          "L'objectif de CMake n'est pas de générer des Makefiles, mais un projet de compilation."
          C'est à mon avis une mauvaise approche. Chaque type de projet a ses fonctions spécifiques, et le plus petit dénominateur commun peut-être difficile à déterminer. De plus, l'outil doit génerer des sorties compliquées, à adapter au gré des versions des cibles (les IDEs)

          QMake génère aussi des projets d'IDE et des Makefiles, mais il est incapable de rajouter des taches de compilation supplémentaires pour autres choses que make ! Je ne parle même pas de la compilation croisée.

          Les systèmes de compilations devraient au contraire se concentrer sur le centre de leur activité : gérer la compilation. Et ce serait plutôt à l'IDE de s'adapter au systèmes de compilations. Le "I" de IDE signifie "Integrated", l'IDE ne devrait rien faire de plus que lier ensemble éditeur, débugger, système de compilation, etc.
  • # Fuyez !

    Posté par (page perso) . Évalué à 10.

    « Daniel J. Bernstein, l'auteur de qmail et djbdns, a proposé une alternative à Make qu'il a appelée redo, mais celle-ci se présente sous forme de notes et non pas de code. »

    AAAAAAAAAAAH

    Fuyez ! Fuyez ! Tant que vous le pouvez encore fuyez !

    Ceux qui ont un jour utilisé qmail me comprendront...
    • [^] # Re: Fuyez !

      Posté par . Évalué à 2.

      Tiens? Il me semblait que qmail était bien vue coté sécurité..
      • [^] # Re: Fuyez !

        Posté par (page perso) . Évalué à 10.

        C'est une légende ça...

        En fait, qmail est tellement secure qu'il se torche le cul avec les conventions de placement de fichiers, et met tout dans /var/qmail. Tu peux pas le changer, c'est hardcodé (sinon ça serait pas secure).

        Ensuite, le principal facteur de sécurité est le gros manque de fonctions, c'est à dire qu'un qmail brut n'est capable que de délivrer les mails dans les répertoires perso des utilisateurs système. Il n'y a pas de configuration possible, ça serait pas secure. (les seuls fichiers de "configuration" sont quelques détails qui contiennent uniquement la liste des utilisateurs ou les domaines à relayer).

        S'ajoute à cela la licence jusqu'à récemment non libre, qui fait qu'on ne pouvais pas redistribuer le code source modifié. Résultat, il n'y a pas eu de fork pour ajouter des fonctionalités *. Donc si tu te retrouves avec des vrais besoins (gérer plusieurs domaines, avoir des utilisateurs non système, ...), t'es obligé d'y aller avec une mixture de logiciels externes (vpopmail, qmailadmin par exemple) + de patchs trouvés au hasard sur des mailing lists * (patchs étant incompatibles entre eux, il faut bien entendu faire l'adaptation soi même).

        Finalement, ça fait une masse d'ajouts de provenance plus ou moins douteuse, dont on n'a pas de visibilité sur les bugs, et encore moins sur les failles de sécurité. Sans oublier le fait qu'à cause de licence et de la maltraitance des conventions unix, qmail n'est pas packagé dans les distributions majeures. Et comme tout le monde le sait, ne pas installer un logiciel en utilisant le système de paquets revient à s'exposer à de nombreux ennuis...

        En bref, qmail lui même n'a pas de problèmes de sécurité, mais si tu veux l'utiliser en production tu va devoir choisir entre la sécurité et les fonctionnalités. Et en fait, sauf à mettre en place un relais pour spammeur, tu n'a pas le choix. Donc qmail est complètement impossible à maintenir, en plus de t'obliger à y rajouter des failles de sécurité et des bugs échapants à la loi de Torvalds, au prix d'une grosse prise de tête.

        Moralité : fuyez :)

        * Ces dernières années on a vu un fork majeur et des compilations de patchs se former, mais qmail n'est plus à ses heures de gloire, ces éléments sont maintenus en pointillets si maintenu, et l'origine des modifications reste toujours aussi douteuse.
    • [^] # Re: Fuyez !

      Posté par (page perso) . Évalué à 2.

      « Ceux qui ont un jour utilisé qmail me comprendront... »

      ... et daemontools :(
  • # Y'en a déjà des kilos...

    Posté par . Évalué à 0.

    ...de remplaçants pour make.

    Mais il semble y avoir un consensus dans le monde linux autour de make mais surtout des autotools de la mort.
    • [^] # Re: Y'en a déjà des kilos...

      Posté par (page perso) . Évalué à 7.

      Il y avait aussi plein de remplaçants de CVS avant l'arrivée de Git (et mercurial). Ça ne l'a pas empêché de marquer une nette avancée.

      Ça ne veut pas forcément dire que redo va devenir l'équivalent de git, mais l'argument qu'il y a déjà plein d'outils pour faire ça n'est pas suffisant pour le rejeter.
      • [^] # Re: Y'en a déjà des kilos...

        Posté par . Évalué à 1.

        Je suis d'accord avec ça.

        Mais il se trouve qu'il y a une longue histoire autour de la gestion de version. Il y a eu rcs puis cvs puis svn plus git/mercurial et d'autres. Et a chaque fois les développeurs ont migré en masse.

        Pour ce qui est de autotools/make il y a eu des tas d'alternatives bien meilleures et la majorité des développeurs n'ont pas voulu migrer.
        • [^] # Re: Y'en a déjà des kilos...

          Posté par (page perso) . Évalué à 7.

          Je pense que les alternatives comme ANT... sont trop flêchés sur un langage : Java, C++... du coup, on n'a pas du tout envie de le mettre sur autre chose.

          Il faut vraiment un outil qui à la base ne pense pas pour un langage.
  • # make ?

    Posté par . Évalué à 9.

    Je pense pas que make soit un pb, il fait ce pourquoi il a été conçu : gestion de dépendance. Par contre sont gros problème c'est pour debugger des makefile.

    Le pb c'est que les gens veule un truc plus haut niveau : filer une liste de fichiers a compiler, des options de génération (compil/link) et éventuellement faire des test dynamique sur les dépendance (version des lib, support de tel fonction, ...). Et aussi avoir une GUI a la kconfig, pour permettre de sélectionner des options de config.

    C'est ce que font les autotools, mais franchement je trouve qu'ils sont une usine a gaz (makefile générer inbitable, pb de cross compilation, trop complex (les devs ne comprenne pas forcement ce qu'ils font)). Je ne parle même pas du libtool qui vient avec.

    Il y a cmake, mais la derniére fois que j'ai regardé ca ma pas convaincu.

    ps :

    redo-ifchange $1.c

    gcc -MD -MF $3.deps.tmp -c -o $3 $1.c

    DEPS=$(sed -e "s/^$3://" -e 's/\\//g' <$3.deps.tmp)

    rm -f $3.deps.tmp

    redo-ifchange $DEPS

    et ben ca m'a pas l'air très simple
    • [^] # Re: make ?

      Posté par (page perso) . Évalué à 3.

      Go fournit des includes pour Makefile qui s'occupent à peu près de tout. Reste à spécifier la liste des fichiers à compiler. Ca a l'avantage de se reposer sur quelque chose qui existe partout (les Makefile) et de rester très simple.
      include ../../../Make.inc

      TARG=container/vector
      GOFILES=\
        intvector.go\
        stringvector.go\
        vector.go\

      include ../../../Make.pkg

      http://golang.org/doc/code.html
      • [^] # Re: make ?

        Posté par . Évalué à 2.

        Mouai enfin moi 80% du temps si c'est des choses aussi simples mon Makefile c'est ça :
        SRC=$(wildcard *.c)
        OBJ=$(SRC:.c=.o)
        EXE=monprog

        .PHONY: clean mrproper all

        all: $(EXE)

        $(EXE): $(OBJ)
        gcc $^ -o $@

        %.o: %.c

        clean:
        rm $(OBJ)

        mrproper: clean
        rm $(EXE)


        Ou à peu près et je peux modifier mes options de compilation soit en dur dans le makefile soit avec des variables d'environnement.

        Et faire de même avec go n'est pas compliqué.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: make ?

          Posté par (page perso) . Évalué à 2.

          Ça ne me paraît pas idéal comme Makefile : si tu modifies un .h et que tu relances make, il ne se passera rien.
          • [^] # Re: make ?

            Posté par . Évalué à 1.

            Je l'ai fais de tête c'est un oublie simple à prendre en compte.

            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

            • [^] # Re: make ?

              Posté par . Évalué à 3.

              Je l'ai fais de tête c'est un oublie simple à prendre en compte.

              Euh, si tu ajoutes une version correcte de la fonctionnalité demandée par Bruno (dépendance vers les headers utilisés par un .c) à un Makefile aussi simple, ça devient de loin la partie la plus compliquée...
              • [^] # Re: make ?

                Posté par . Évalué à 1.

                Ah bon ? (Raz le bol des balises codes à la noix de templeet)
                https://yanopaste.jujunie.com/index.php?id=20110117085221_20(...)

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: make ?

                  Posté par . Évalué à 1.

                  J'ai rien dis. Je me suis planté oui il faut utiliser gcc pour analyser chaque fichier source.

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: make ?

                Posté par . Évalué à 1.

                Pas nécessairement, si l'on proscrit le make récursif. Et qu'on accepte de devoir lancer make 2 fois pour avoir les dépendance correctes : l'idée c'est de générer les .depends en même temps que la compilation, et comme ça ne change pas souvent, la plupart du temps c'est suffisant (pas besoin de cible spéciale "depend").
                http://mad-scientist.net/make/autodep.html pour les curieux.
      • [^] # Re: make ?

        Posté par . Évalué à 2.

        Oui je connais les templates makefile qui simplifie la vie.

        Mais pour en avoir fait une au boulot (pour un projet de plusieurs milliers de fichiers) et ben je regrette de n'avoir pas pu utiliser une autre option a l'époque.

        Le code de la template est plein de magic make incompréhensible. Des qu'il faut modifier le comportement, c'est la galère. Ca devient un truc pas maintenable, compris par quelques gurus.

        On ne fait pas de make recursif, chaque sous projet inclue ses makefiles (avec la commande include de make). Et ben une boulette dans un sous makefile peu faire tout péter sans moyen simple de le debugger.

        Les gens développant les sous projet ne sont pas familier avec make et font vite des boulettes qui fait tout planter.

        Bref make c'est simple sur des petits projets. Mais sur des gros projets ou il faut gérer différentes versions de build (dans des répertoires différent), de la compilation conditionnelle, des tests dynamiques, ..., on arrive vite a devoir réinventer la roue et obtenir un truc bancale.

        Et d'ailleurs il n'y a pas de solution de template makefile générique. La plus évolué étant le système du kernel Linux.
        • [^] # Re: make ?

          Posté par . Évalué à 2.

          > Et d'ailleurs il n'y a pas de solution de template makefile générique. La plus évolué étant le système du kernel Linux.

          GNUStep, L4/fiasco (inspirée de kbuild), Kbuild ça fait dejà 3. Viennent ensuite les ports (pkgsrc, FreeBSD, OpenBSD), les chaines de compilations emarquées, ...

          s/n'y a pas/y a plein/g. Je vois mal comment cela pourrait être générique, cela démontre plustôt la souplesse de make; il y moyen de faire de trucs propre, aussi ;) .
          • [^] # Re: make ?

            Posté par . Évalué à 2.

            C'est bien ce que je dis chacun est obligé de refaire un truc a sa sauce avec les pbs que ca comporte (maintenance, pour chaque système il faut apprendre comme il fonctionne, ...).

            Je vois mal comment cela pourrait être générique, cela démontre plustôt la souplesse de make;

            Certes mais tout les projets ne veulent/peuvent pas avoir des experts make dans leur équipes.
            Compte le nombre de gens qui connaisse bien les templates que tu as cité (ie seront corrigé un bug dedans, ajouter des nouvelles fonctionnalitées).

            il y moyen de faire de trucs propre, aussi ;) .
            Comme dans a peu pres tout les langages.
      • [^] # Re: make ?

        Posté par (page perso) . Évalué à 2.

        J'avais fait il y a longtemps un Make-makefile plus puissant que mkmf.
        Si ça peut intéresser quelqu'un en voici le source : http://pjarillon.free.fr/docs/mkmkf.c
    • [^] # Re: make ?

      Posté par (page perso) . Évalué à 2.

      > Je pense pas que make soit un pb, il fait ce pourquoi il a été conçu : gestion de dépendance.

      Bah, même pour la gestion des dépendances, make n'est pas si bien que ça. Ce n'est pas facile d'avoir un Makefile générique qui sache recompiler juste les fichiers nécessaires quand un .h a été modifié. Ou qui ne refasse que la phase d'édition de liens quand on change LDFLAGS.
      • [^] # Re: make ?

        Posté par . Évalué à 1.

        > Ou qui ne refasse que la phase d'édition de liens quand on change LDFLAGS.
        un truc du genre ?
        unlink:
        find . -name \*.a -o -name $(EXE) | xargs rm -f
        • [^] # Re: make ?

          Posté par (page perso) . Évalué à 2.

          Ça, c'est la règle pour le faire à la main. Je voudrais plutôt un truc du genre :

          mon_executable: $(OBJS) $(LDFLAGS)

          pour indiquer à make qu'il doit reconstruire 'mon_executable' si LD_FLAGS change. Mais je ne sais pas faire ça sans avoir à mettre LDFLAGS dans un fichier à part.
          • [^] # Re: make ?

            Posté par . Évalué à 2.

            Oui en effet, il doit y avoir moyen de bidouiller avec un fichier à part. Mais le cas de changer les LD_FLAGS doit arriver si souvent que lancer une target à la main n'est pas la mer à boire amha.
      • [^] # Re: make ?

        Posté par . Évalué à 2.

        Le truc classique c'est de mettre ton makefile en dépendence, comme ca si tu l'édites (pour changer les flags) tout ce rebuild.

        Après s'ils sont passé par paramètre c'est la misère.
  • # ... as usual

    Posté par (page perso) . Évalué à 8.

    Cet homme est un peu le Le Pen de l'info, il soulève de vrais problèmes (dns, mail, make) mais il apporte de mauvaises réponses.

    Pour preuves, on utilise toujours ISC bind qui est effectivement une horreur de conf et de code.

    (ouahouh, \o/ j'ai réussi un point GodWin en début de thread)
    • [^] # Re: ... as usual

      Posté par (page perso) . Évalué à 1.

      Bah, les nazis ont fait de bonnes choses, les autoroutes par exemple. Là c'est pareil, il a fait le format maildir. Après le reste...
  • # Et les ficher Jam ?

    Posté par . Évalué à 1.

    Il y a quelques temps, j'étais tombé sur cette page web:

    http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)

    jam semble performant. Une autre page montre les diverses fonctionnalités des systèmes de build:

    http://www.scons.org/wiki/SconsVsOtherBuildTools

    Je ne sais pas si certains d'entre vous ont utilisé jam, mais si oui, j'aimerais bien avoir leur(s) avis.
  • # J'attends désespérément un moteur de production potable...

    Posté par (page perso) . Évalué à 6.

    Et rien ne m'a totalement convaincu jusque là. Dès que les dépendances sont un peu complexes (générer un programme qui génère du code, pour enfin générer le projet principal, par exemple...), il faut des kilomètres de configuration. Sans parler du support pour la compilation en parallèle, souvent mal supportée. CMake fait le boulot, mais au final pas si bien documenté, et trimballe avec lui ses défauts et ceux de Make. Et quand quelque chose ne marche pas, c'est pas particulièrement agréable à debugger.

    Les solutions modernes, telles Ant ou Rake, sont souvent soit horriblement verbeuses, soit très légo: l'on assemble des blocs trouvés sur le Net, et si l'on a besoin de quelque chose d'un peu ésotérique, c'est l'horreur. Ceux qui me déplaisent le moins sont Scons et OMake, ce dernier, écrit en OCaml, étant mon favori dans mes projets perso.

    Comme d'ailleurs les langages de programmation, tous ces outils ont été écrits pour résoudre des problèmes particuliers, et je crains qu'il n'existe pas de solution vraiment universelle, contrairement à la gestion de sources, par exemple, où Git et Mercurial proposent un modèle très solide.

    Snif.
  • # Rien ne vaut un bon benchmark bien viril

    Posté par . Évalué à 3.

    C'est bien beau de discuter des heures sur les systèmes de build existant, mais bon, la discussion, c'est un truc de gonzesses... Les hommes, les vrais, ne jugent qu'à partir de benchmarks :

    http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)
    • [^] # Re: Rien ne vaut un bon benchmark bien viril

      Posté par . Évalué à 2.

      Ouai mais non, la vitesse n'est rien sans contrôle. Je préfère un builder qui a une vitesse plus faible mais qui est utilisable même par une loutre qu'un builder ultrarapide où il faut le recompiler à chaque fois qu'on le modifie.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Rien ne vaut un bon benchmark bien viril

        Posté par . Évalué à -1.

        Un outil pour développeur qui a pour premier but d’être utilisable par une loutre, il mérite d’être atomisé puis dispersé dans l’espace. Si c’est pour obtenir des trucs comme Delphi, merci mais non merci.
        • [^] # Re: Rien ne vaut un bon benchmark bien viril

          Posté par . Évalué à 7.

          C'est vrai, il vaut mieux un outil qui oublie de te recompiler un fichier après une modif en pleine séance de déverminage (de préférence liée à un bug sournois genre problème de synchronisation entre threads), histoire de bien rigoler :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.