Technical discussions | Discussions techniques
|
aCOSwt, Friday 07 December 2012 à 23:15
|
|
Subscription date : 07 October 2012
Messages : 22
|
Bon... on va le faire en français... comme cela... ce sera plus... confidentiel ! 
Bon... alors... je vous ai déjà fait pas mal de compliments sur ce forum... Bon... Point trop n'en faut non plus... hein ?
C'est à dire que... j'aurais bien quelques... défauts... mer... :-? ... enfin... souçis à signaler...
Je peux les écrire en police de 2 si cela fait qu'ils passent mieux...
En deux mots comme en cent donc... ce serait rudement bien si, dans vos CMakeLists...
1/ Les variables binaires du genre enable-doncky, enable-alsa... pouvaient être testées comme des variables binaires. Je veux dire par là surtout pas testées STREQUAL "no" ou STREQUAL "yes"...
C'est galère ça ! Vraiment galère ! :
CMake considers an empty string, "FALSE", "OFF", "NO", or any string ending in "-NOTFOUND" to be false. (This happens to be case-insensitive, so "False", "off", "no", and "something-NotFound" are all false.) Other values are true. Thus it matters not whether you use TRUE and FALSE, ON and OFF, or YES and NO for your booleans
Vous comprenez alors que certains automates positionnent ces variables à ON / OFF par exemple et pis après... badabem quand ça arrive dans votre cmakelist ! 
2/ Les variables binaires du genre enable-doncky, enable-alsa... c'est rudement pratique et... tellement pratique que... ce serait vachement bien s'il... y en avait... partout ! enable-python / vala / ruby / mono / clock... bref... partout quoi !
enable-sharedlibs...  non ! jdéco... ! 
Pourquoi ? Et bhé parceque pour les applets / fonctionnalités / bindings qui n'ont pas de test préalable, le code sera installé dès lors que les librairies nécessaires sont détectées présentes sur le système. Ceci ayant pour fâcheuse conséquence d'établir une dépendance de vos package sur une libxyzt à... l'insu du plein gré du système.
=> C'est à dire entre autres side effects mineurs... le jour où j'upgrade libxyzt, mon système ne sait pas qu'il faut rebuilder cairo-trucs ! et le jour où je vire libxyzt et ben... badabem mes docks et... je ne sais plus pourquoi ! Enfin... plein de trucs de le genre pas cool quoi !
Bon... allez... je vous laisse... y'a du taf là !
Et... comme dirait Linus... Fix that already !
Bon... je peux évidemment vous proposer un patch si cela vous aide mais en général... les devs... aiment pas quand on touche leur makefiles... 
|
|
matttbe, Sunday 09 December 2012 à 12:42
|
|
Subscription date : 24 January 2009
Messages : 12573
|
1/ Les variables binaires du genre enable-doncky, enable-alsa... pouvaient être testées comme des variables binaires. Je veux dire par là surtout pas testées STREQUAL "no" ou STREQUAL "yes"...
C'est galère ça ! Vraiment galère ! : Yep, j'y avais déjà pensé mais c'est un truc à faire en "début de cycle", lorsque la version est en alpha et pas en beta/RC. Donc c'est le bon moment pour faire ça. Si Fabounet est d'accord, je veux bien m'en occuper quand j'aurai un peu de temps 
2/ Les variables binaires du genre enable-doncky, enable-alsa... c'est rudement pratique et... tellement pratique que... ce serait vachement bien s'il... y en avait... partout ! enable-python / vala / ruby / mono / clock... bref... partout quoi !
enable-sharedlibs... non ! jdéco... !
Pourquoi ? Et bhé parceque pour les applets / fonctionnalités / bindings qui n'ont pas de test préalable, le code sera installé dès lors que les librairies nécessaires sont détectées présentes sur le système. Ceci ayant pour fâcheuse conséquence d'établir une dépendance de vos package sur une libxyzt à... l'insu du plein gré du système.
=> C'est à dire entre autres side effects mineurs... le jour où j'upgrade libxyzt, mon système ne sait pas qu'il faut rebuilder cairo-trucs ! et le jour où je vire libxyzt et ben... badabem mes docks et... je ne sais plus pourquoi ! Enfin... plein de trucs de le genre pas cool quoi ! Mmh, si tu compiles un truc avec la lib X installée, il est pour moi normal que le dock compile les modules qui utilisent cette lib. Après, c'est à la distrib de gérer les dépendances 
C'est pour ça qu'il est souvent conseillé de compiler dans un environnement de build (un chroot dans l'idéal) et de regarder les dépendances utilisées (ex: avec un script qui utilise 'ld' pour obtenir la liste des librairies/paquets utilisés).
D'un autre côté, on pourrait ajouter la possibilité de compiler ou non chaque plugin mais alors on revient au problème que l'on a avec Debian: dans les paquets des dépôts officiels, chaque plugin est dans un paquet différent. Or, si tu commences à enlever les plugins avec les vues, l'applet clock, switcher, musicPlayer ou autres, ça ne ressemble plus à rien. Les thèmes que tu vas charger seront bogués, etc.
Je comprends qu'il peut être intéressant de ne pas installer un plugin s'il vient avec des dépendances (ex: weblets qui demande webkit, l'interface mono qui demande mono, etc.) mais ça ne concerne pas la majorité des plugins et il suffit de ne pas avoir la lib installé pour ne pas les avoir (si on les a, c'est que l'on utilise la lib... si maintenant ton système ne gère pas bien l'arbre des dépendances, c'est délicat en effet...).
Donc pour moi, si c'est pour ajouter plus de 'enable-(...)', ce serait uniquement pour les plugins qui demandent plus de dépendances (mais c'est généralement le cas ; ex: Weblet, GMenu, etc. mais pas (encore) Recent-Events, etc.)
Bon... je peux évidemment vous proposer un patch si cela vous aide mais en général... les devs... aiment pas quand on touche leur makefiles... En effet, c'est délicat de toucher à ces fichiers 
Mais si c'est bien expliqué comme le passage des strings en booléens tout en respectant un même 'layout', ça va (mais je préfère tout de même attendre la réponse de Fabounet avant de le faire ) |
|
aCOSwt, Sunday 09 December 2012 à 15:00
|
|
|
fabounet, Tuesday 11 December 2012 à 17:01
|
|
|
matttbe, Sunday 16 December 2012 à 03:12
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Voilà, les rev 1294 (core) et 2648) (plug-ins) devraient fixer ce bug
Comme marqué en commentaire, il faut maintenant utiliser ON/OFF/TRUE/FALSE pour les flags CMake. Les applets avec des dépendances (module/exécutables) peuvent maintenant être activées ou désactivées vie un enable-...=ON/OFF (les applets stables sont toujours activées par défaut). Ex: (pour compiler le dock avec les applets instables): cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -Denable-network-monitor=ON -Denable-doncky=ON -Denable-scooby-do=ON -Denable-disks=ON -Denable-global-menu=ON -Denable-vala-support=ON
Et pour le core avec la session Cairo-Dock: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -Denable-desktop-manager=ON |
|
aCOSwt, Sunday 16 December 2012 à 18:41
|
|
Subscription date : 07 October 2012
Messages : 22
|
enable_if_not_defined...
Great ! Great idea ! I like that !
Solution très gracieuse !
En bref ! Sa'm'va impec !
Merci vraiment, cela à l'air de rien mais cela va considérablement me simplifier la tâche !
EDIT :  J'avais pas vu ! Dimanche 3h12 !! ... Hé bhé ! C'est qui le chef de projet ?... juste pour que j'évite de candidater quoi...  |
|
matttbe, Monday 17 December 2012 à 15:56
|
|
Technical discussions | Discussions techniques
|
Français
alors... si cela peut t'aider...
Online users :