Lorsque l’on linke des programmes on s’appuie sur des librairies statiques.

Le problème c’est que l’on peut en ajouter plein lors de la compilation et même si aucun symbole n’est utilisé on va charger cette lib au démarrage de l’application.

Cela va ralentir le démarrage de l’application.

On a plusieurs méthode pour réduire cela:

  1. Retirer chaque lib de la liste des librairies à utiliser et voir si ça linke (long et fastidieux)
  2. Utiliser une application dédiée pour cela => elf-dissector

Elf-dissector est une application développé par Volker Krause (kdepim dev + Qt Dev + KDAB dev + …. :) ) donc pas un inconnu :)

Ou trouver Elf-dissector ?

Dans le git de KDE :

“git clone git://anongit.kde.org/elf-dissector”

Compilation:

Il nécessite libelf-devel/binutils/libdwarf-devel/gnuplot

Une fois cela installé il y a plus qu’à faire mkdir build && cd build && cmake -D<….> ../ && make install

C’est vraiment tout simple.

Utilisation:

exemple: elf-dissector /opt/kde5/lib64/libKF5MailCommon.so.5

C’est une application qui va vous permettre de voir quelles libs sont utilisées et ainsi voir si elles sont nécessaires ou non.

Il y a  6 onglets:

  • Elf structure: nous fournit la structure de la librairie (on peut voir le point d’entrée etc.
  • Size Tree Map permet de voir l’organization dans la librairie
  • Dependancy c’est vraiment l’onglet le plus utile il permet de voir les différentes librairies utilisées et voir le nombre de symboles utilisés dans chaque lib. On peut voir cette qui sont chargées mais qui ne sont pas utile. Si l’on clique sur un item on peut voir les symboles utilisées et donc ceux qu’on doit supprimer si l’on veut plus avoir une dépendance sur telle ou telle lib.
  • Issue permet de voir les erreurs dans la librairie ça prend énormément de ressources donc à manier avec parcimonie

Après vous avez plus qu’à réduire le nombre de bibliothèques utilisées pour votre application.

Attention les dépendances peuvent aussi venir de dépendances indirectes donc difficile des fois à faire les ménages.

Mais cette application nous a permis de réduire le temps de chargement de KMail de 1.3 secondes à 0.6 seconde donc vraiment utile.

Clang fournit dans sa suite divers plugins et aussi un analyser statique de code.

Il va simplement analyser le code compilé par clang et il va en faire un rapport en sortie.

Donc tout code non compilé par Clang ne sera pas analysé forcément. Genre il ne va pas aller chercher du code

ou il y a un  #ifdef OPTION par exemple si on n’a pas définit OPTION lors de la compilation.

Comment l’utiliser?

Très simple:

Pour un programme compilé genre kdepim:

mkdir build && cd build && CXX=clang++ CC=clang scan-build -k cmake -DCMAKE_BUILD_TYPE=Debug ../
scan-build -k -o results make

Vous laissez builder et vous aurez le résultat dans le répertoire results sous forme de fichier html.

Attention il peut générer des faux positifs on ne peut pas corriger sans se poser des questions mais ça donne de très bonnes informations sur les erreurs possibles dans le code.

Je vous laisse lire les autres options sur le site officiel http://clang-analyzer.llvm.org/scan-build.html

Les développeurs KDE ne sont pas en reste pour ce qui est des outils pour aider à améliorer la qualité du code.

Sérgio Martins a développé “Clazy” un outils qui utilise Clang pour rechercher et avertir de certaines améliorations à faire dans votre code. Certains de ces plugins peuvent directement modifier le code source.

Comment le builder ?

Déjà récupérer le code source git clone git://anongit.kde.org/clazy

Il faut clang-devel >= 3.6

Ensuite il faut le builder et cela contre clang.

mkdir build && cd build && cmake  -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_INSTALL_PREFIX=<path> …/ && make install

Maintenant il faut s’assurer que <path>/lib64/ est dans votre LD_LIBRARY_PATH sinon ça ne marchera pas.

Dès que tout cela est fait vous pouvez l’essayer sur un projet.

Comment l’utiliser ?

Il faut export la variable CXX

export CXX=”clazy”

Ensuite il faut dire ce que vous voulez évaluer.

Si vous voulez avoir tous les warning reportés par clazy, il suffit d’exporter une deuxième variable:

export CLAZY_CHECKS=all_checks

Après il faut reconfigurer le build sur votre projet

cmake -DCMAKE_INSTALL_PREFIX=<path> ../

et là vous aller pouvoir voir tous les variables et les infos résultant.

Les divers plugins:

  • bogus-dynamic-cast
  • foreacher
  • global-const-char-pointer
  • inefficient-qlist
  • qstring-uneeded-heap-allocations
  • qstring-arg
  • qstring-ref
  • function-args-by-ref
  • qmap-with-key-pointer
  • non-pod-global-static
  • reserve-candidates
  • variant-sanitizer
  • virtual-call-ctor
  • missing-typeinfo
  • implicit-casts
  • old-style-connect
  • detaching-temporary
  • assert-with-side-effects
  • qgetenv

Comment faire les fixes directement dans le code?

C’est très simple :) Il suffit de le dire à Clazy en exportant la variable CLAZY_FIXIT

Par exemple:

export CLAZY_FIXIT=”fix-missing-qstringref”

Il y a que quelques plugins qui permettent la modification directe.

export CLAZY_FIXIT=”fix-old-style-connects” (change le style de connexion signal/slots (la nouvelle API qui est arrivée avec Qt5)
export CLAZY_FIXIT=”fix-missing-qstringref” (ça adapte le code pour utiliser const + ref lorsque c’est possible)
export CLAZY_FIXIT=”fix-fromCharPtrAllocations” (les 3 autres c’est pour réduire l’allocation lors de l’utilisation des QString)
export CLAZY_FIXIT=”fix-qlatin1string-allocations”
export CLAZY_FIXIT=”fix-fromLatin1_fromUtf8-allocations”

CLAZY_FIXIT ne permet pas de faire tout ensemble c’est un plugin par compilation ce qui est un peu logique car changer un fichier en court de route et remodifier encore derrière serait très risqué)

Mais pour fixer kde j’ai créé un script. Vous pouvez l’utiliser clazy-compile

il suffit de le renommer en .sh et le l’exécuter il fait tout pour vous.

Le futur ?

Ben il y a toujours des vérifications de code à faire et des optimisations donc ça va continuer. Mais j’en sais pas plus :)

Depuis la semaine dernière j’utilise aucune application kde4.

ça veut dire que j’utilise kdepim kf5.

Oui j’ai tenté mais je l’ai pas fait n’importe comment. Déjà j’ai mis en place une vraie migration. (les folders n’étant pas migré ça posait quelques problèmes). De plus j’avais déjà fait un maximum de test à coté.

Mais bien sur ça vaut pas le test en live :) Et là ben… comment dire… des bugs à profusion. Genre kaddressbook ne pouvait pas stocker les nouveaux contacts.

Donc j’ai passé du temps à rendre kdepim utilisable.

Mais maintenant c’est parti pour une longue chasse aux bugs :)

L’objectif c’est 15.08.

Est ce que je crois que ça sera opérationnel ? Heu… bien sur :) Enfin si on est plus que 2 à bosser dessus. Dan est en train d’améliorer Akonadi, et moi je fixe le reste.

Donc forcément ça prend du temps.

Faut en même temps avoir des gens qui testent kf5 :)

Est ce que je vais laisser tomber kde 4.14 ?

Bien sur que non je vais continuer à le fixer sans problème surtout que je suis pas sur que kdepim kf5 sorte vraiment pour la 15.08.

Là aussi j’ai besoin de bugs reports.

Voilà :)

Pendant qq semaines j’ai pas compris pourquoi j’avais pas de systray.

C’était ennuyeux pour konversation ou KMail.

Eike Hein m’a donné la solution: libdbusmenu-qt5 et bien sur qt5.4 et sni-qt4 :)

Oui ça fait beaucoup mais sans cela ça marche pas et c’était très ennuyeux.

Voilà pour ceux qui cherchaient au cas ou.