[+] Mauvaise catégorie !

• [^]Re: Mauvaise catégorie !

  Posté par baud123 (Jabber id, page perso, ) le 08/03/2010 à 09:56. (lien). Évalué à 8.

  oui et ? tout comme OpenWrt : http://linuxfr.org/2010/03/05/26546.html
  
  c'est dans la section Logiciel et le thème Hardware, vu que c'est fortement lié à celui-ci et sert pour l'embarqué, tu aurais proposé quel autre thème ?

  • [^]Re: Mauvaise catégorie !

    Posté par Thomas Petazzoni (page perso, ) le 08/03/2010 à 20:23. (lien). Évalué à 2.

    c'est dans la section Logiciel et le thème Hardware, vu que c'est fortement lié à celui-ci et sert pour l'embarqué, tu aurais proposé quel autre thème ?
    
    À mon avis, il manque un thème Embarqué. Et je n'ai jamais rien compris à la distinction section et thème faite par LinuxFr pour classer les dépêches.

    • [^]Re: Mauvaise catégorie !

      Posté par baud123 (Jabber id, page perso, ) le 08/03/2010 à 21:54. (lien). Évalué à 5.

      À mon avis, il manque un thème Embarqué.
      
      alors, je te redonne la réponse classique de Oumph< :
      - tu identifies le thème et tu fournis un logo (SVG de préférence et sous licence libre et qui passe bien sur une page telle que [https://linuxfr.org/moderateurs/moderation.html#themes] pour s'assurer que le détourage et le transparent passent bien sur à peu près tout fond)
      - tu l'indiques sur http://linuxfr.org/tracker/
      - et généralement ça peut être pris en compte rapidement ;-)
      
      Et je n'ai jamais rien compris à la distinction section et thème faite par LinuxFr pour classer les dépêches.
      
      euh, bin, c'est comme sur /. non ? :D sérieusement, c'est des catégories / sous-catégories qui apparaissent du côté gauche sur des pages comme :
      - http://linuxfr.org/sections/Articles comme toutes les dépêches "articles" ou https://linuxfr.org/sections/Cin%C3%A9ma pour les dépêches préférées sur DLFP
      - http://linuxfr.org/topics/Game pour les dépêches concernant le thème jeu ou https://linuxfr.org/topics/Science pour les sujets scientifiques
      (oui, tu auras remarqué la distinction topics / thèmes (ça fait toujours bien sur un site francophone :D).
      
      'fin bon, c'est aussi un peu pour ça que j'avais demandé des tags à une époque [http://linuxfr.org/tracker/623.html] ;-)

./configure

• [^]Re: ./configure

  Posté par pankkake (Jabber id, page perso, ) le 08/03/2010 à 10:33. (lien). Évalué à 4.

  Ça a été un des projets internes de Gentoo, mais j'ai l'impression que c’est tombé à l'eau.

  • [^]Re: ./configure

    Posté par Damien Thébault (Jabber id, page perso, ) le 08/03/2010 à 20:54. (lien). Évalué à 3.

    Ça s'appelle "confcache", j'ai pas trop regardé comment ça marche en interne, mais il faut le désactiver pour certains paquets. En fait, il manque certaines choses dans les autotools, par exemple le système de cache ou le fait d'être obligé d'avoir accès à la target pour certains paquets (pour résoudre cette dernière chose il y a bien le projet scratchbox, mais c'est un peu overkill je trouve).
    
    Je rève d'un monde où tout ça serait résolu mais le projet des autotools va toujours dans la même direction donc il y a peu de chance d'avoir du neuf par là)

    • [^]Re: ./configure

      Posté par Thomas Petazzoni (page perso, ) le 08/03/2010 à 21:27. (lien). Évalué à 2.

      Tiens, je ne connaissais pas de confcache. Qu'est-ce que ça apporte par rapport au mécanisme de cache intégré aux autotools ?
      
      Concernant le fait d'être obligé d'accéder à la machine cible, les autotools permettent d'indiquer à ./configure le résultat qu'aurait un test si il était fait sur la machine cible, sans avoir besoin d'y accéder effectivement.
      
      Par exemple, quand les autotools veulent tester si ta machine cible et big ou little endian, tu passes ac_cv_c_bigendian=yes quand tu es big endian, et ac_cv_c_bigendian=no quand tu es little endian, et le tour est joué. C'est le rôle du système de build autour de passer les options qui vont bien.
      
      Et effectivement, je trouve aussi que Scratchbox est une approche overkill. D'ailleurs, avec la fusion entre Maemo et Moblin (pour donner MeeGo), ils ont annoncé l'abandon du format de paquet Debian (utilisé par Maemo) pour passer à RPM (utilisé par Moblin). Du coup, je me demande ce qu'il va rester de Scratchbox qui était quand même très fortement orienté paquet Debian.

      • [^]Re: ./configure

        Posté par Matthieu C () le 09/03/2010 à 11:10. (lien). Évalué à 3.

        les autotools c'est quand même la grosse merde pour faire de la cross compilation : entre les test qui cherche a exécuter des programmes, d'autres test qui hardcode des résultats dans le cas de cross compilation, encore d'autre qui cherche des headers/libs dans /lib ou /usr il faut souvent les patcher.
        
        Je ne parle même pas de libtool qui fait les 3/4 du temps pas ce que tu veux.
        
        Et le plus triste c'est qu'il y a souvent un moyen plus ou moins portable de faire le test.
        
        Par exemple, quand les autotools veulent tester si ta machine cible et big ou little endian, tu passes ac_cv_c_bigendian=yes quand tu es big endian, et ac_cv_c_bigendian=no quand tu es little endian, et le tour est joué.
        $ touch endian.c
        $ cc -o endian.o -c endian.c
        $ objdump -a /tmp/endian.o
        
        ou encore
        
        $ echo "unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 'E';" > end.c
        $ gcc end.c -c -o end.o
        $ od -t x1 end | grep -q '42 *49 *47 *45' && echo big

        • [^]Re: ./configure

          Posté par Didier (page perso, ) le 09/03/2010 à 21:21. (lien). Évalué à 3.

          Tes tests utilisent objdump et od qui ne sont pas forcément installés partout, donc pas utilisables pas les autotools pour leurs tests.
          
          Pour info, voici la liste des commandes qui sont considérées comme "sûres" :
          awk cat cmp cp diff echo egrep expr false grep install-info
ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch tr true
ar bison cc flex install ld ldconfig lex
make makeinfo ranlib texi2dvi yacc

          Voir http://www.gnu.org/software/autoconf/manual/autoconf.html#Po(...) et plus particulièrement http://www.gnu.org/software/autoconf/manual/standards.html#U(...)
          
          Et encore, il y a des conseils d'utilisation pour éviter de rencontrer des problèmes sur certaines plates-formes : http://www.gnu.org/software/autoconf/manual/autoconf.html#Li(...)

        • [^]astuce du jour

          Posté par Krunch (Jabber id, page perso, ) le 09/03/2010 à 22:55. (lien). Évalué à 5.

          gcc peut lire le programme à compiler sur son entrée standard.
          
          $ echo "unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 'E';" | gcc -x c -c -o end.o -

          --
          Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
          pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

• [^]Re: ./configure

  Posté par tankey () le 08/03/2010 à 10:49. (lien). Évalué à 4.

  Peut être parceque, là, cela ne factoriserai pas le temps de travail ? :p
  Dans la mesure où tu va avoir besoin de telles options pour tel configure de tel logiciel, et que chaque options de chaque configure peux varier. Du coup, au mieux tu aurais une belle liste de départ, avec des catégories nommées par briques logicielles, et comprenant chacune la liste des options non communes autotools, mais certaines redondantes quant même (dans la mesure où tu peux vouloi telle option pour tel soft, mais pas pour tel autre). Au final, le temps passé à chaque étape se retrouve concentrer sur le temps à passé en début de compilation. Pas de gain de temps, donc.
  Cela doit pouvoir se scripter, ça, c'est typiquement le genre de trucs qu'on peux avoir besoin personnlellement mais qui n'a que peu d'intérêt pour tous : tu connais tes softs, tu sais quelles options tu va choisir, tu le prépare pour toi.
  Non ?

  • [^]Re: ./configure

    Posté par Thomas Douillard () le 08/03/2010 à 19:40. (lien). Évalué à 4.

    En même temps dans les "configure" en général, t'as un paquet de temps à faire des trucs qui varient pas du tout suivant le paquet, genre la détection de l'architecture ou le nombre maximum de lignes traitables par bash.
    
    Il pourrait presque être avantageux de cacher les résultats de ce genre de macros si on est sûr que c'est invariant suivant le paquet.
    
    Cela dit, faudrait toucher aux autotools, donc au final, le jeu en vaut sûrement pas la chandelle ;)

    • [^]Re: ./configure

      Posté par Thomas Petazzoni (page perso, ) le 08/03/2010 à 20:21. (lien). Évalué à 3.

      Il pourrait presque être avantageux de cacher les résultats de ce genre de macros si on est sûr que c'est invariant suivant le paquet.
      
      Et c'est exactement ce que nous faisons, grâce à l'option --cache-file des fichiers de configure. Nous faisons ainsi partager un fichier de cache entre tous les scripts configure, ce qui améliore effectivement significativement le temps d'exécution de ces scripts.
      
      En dehors de ça, il n'y a pas vraiment grand chose que nous puissions faire, je le crains.

• [^]Re: ./configure

  Posté par Thomas Petazzoni (page perso, ) le 08/03/2010 à 20:22. (lien). Évalué à 1.

  Est-ce vraiment nécessaire? Est-ce que les systèmes comme buildroot, qui ont une vision globale de tous les paquets, ne pourraient pas factoriser les tests du ./configure?
  
  Comme dit plus bas, c'est ce que nous faisons avec --cache-file. Voir http://www.gnu.org/software/hello/manual/autoconf/Cache-File(...)
  
  C'est implémenté ici: http://git.buildroot.net/buildroot/tree/package/Makefile.aut(...)

  • [^]Re: ./configure

    Posté par cjlano () le 10/03/2010 à 10:10. (lien). Évalué à 1.

    Merci Thomas pour cette info.
    Je ne connaissais pas l'option --cache-file. Ça risque en effet d'améliorer sérieusement la vitesse des scripts ./configure.
    
    Je teste ça dès que possible :-)

je vote pour (c'est le moment)