Home Forums Wiki Doc Install Extras Screenshots Source Code Projects Blog Users Groups Register
Glx-Dock / Cairo-Dock List of forums Technical discussions | Discussions techniques Quelques souhaits à propos du CMakeLists des plugins
The latest stable release is the *3.4.0* : How to install it here.
Note: We just switched from BZR to Git on Github! (only to host the code and your future pull requests)
Technical discussions | Discussions techniques

Subjects Author Language Messages Last message
[Locked] Quelques souhaits à propos du CMakeLists des plugins
aCOSwt Français 6 matttbe [Read]
17 December 2012 à 15:56

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


Subscription date : 07 October 2012
Messages : 22
matttbe :

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.)

Yep yep yep & re-yep !!!
Yes please and tout ça !
En fait, je pense essentiellement à Mono / Vala / Pulse / Mail / randr.

Sans dec : Pulseaudio par exemple. Je connais deux types de users. Ceux qui ne l'ont jamais installé et ceux qui cherchent désespérément à s'en débarrasser...
Malheureusement pour toi tu l'as par défaut / Tu installes les docks qui la détectent et bing le plugin est automagiquement installé.
Tu parviens à grand peine à virer Pulse et bing tu casses tes plugins !

En fait, ce que je veux dire donc c'est que ce n'est pas nécéssairement parce que tu as la lib installée que tu le souhaites et que donc tu souhaites le plugin qui en dépend.
Tiens... si je pouvais moi... par exemple... je dézinguerais bien volontiers udev... pas vous ?

Bon allez... tant qu'à mettre ses mains dans la graisse... enable-mono / enable-vala / enable-pulse et même si vous prenez l'option enabled par défaut pour des raisons de compatibilité... c'est pas grave... pourvu... qu'on puisse disabler si on veut.

Please.
S'il vous plait.
J'ai plusieurs systèmes en bas âge à nourrir...

En fait de tout vous dire la vérité... mes ebuilds sont en passe d'être acceptés sur sunrise mais pour en arriver là, j'ai du dézinguer à grand coups de sed scripts ces installs automagiques... donc...

EDIT : Si Fabounet resiste... je crois que je n'ai même pas besoin de traverser la Seine pour aller le convaincre... alors... si cela peut t'aider...
Ha... quoique... peut-être...
Mais bon... y'a un pont !

fabounet, Tuesday 11 December 2012 à 17:01


Subscription date : 30 November 2007
Messages : 17118
1/ pas de contre-indication, c'est même pratique

2/
Tu parviens à grand peine à virer Pulse et bing tu casses tes plugins !

effectivement si une lib change son API / disparait, alors tu devras re-compiler les plug-ins qui en dépendent.
mais si tu n'actives pas une applet, il n'y a aucune raison qu'elle pose problème.

ceci dit, il me semble que la plupart des applets qui amènent une dépendance sont désactivables, justement pour le cas où on ne voudrait pas embarquer une dépendance. Par contre, pas grand intérêt de désactiver les autres applets (ça va juste donner de mauvaises idées à certains packageurs ...)

Edit: après lecture du 2ème post, je crois qu'on est d'accord

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


Subscription date : 24 January 2009
Messages : 12573
EDIT : J'avais pas vu ! Dimanche 3h12 !! ... Hé bhé ! C'est qui le chef de projet ?... juste pour que j'évite de candidater quoi...
C'est Fab mais lui il arrive à se réveiller tôt le lendemain pour aller travailler

Mais on accepte aussi tous autres patch réalisés avant 1h du mat'

Technical discussions | Discussions techniques

Subjects Author Language Messages Last message
[Locked] Quelques souhaits à propos du CMakeLists des plugins
aCOSwt Français 6 matttbe [Read]
17 December 2012 à 15:56


Glx-Dock / Cairo-Dock List of forums Technical discussions | Discussions techniques Quelques souhaits à propos du CMakeLists des plugins Top

Online users :

Powered by ElementSpeak © 2007 Adrien Pilleboue, 2009-2013 Matthieu Baerts.
Dock based on CSS Dock Menu (Ndesign) with jQuery. Icons by zgegball
Cairo-Dock is a free software under GNU-GPL3 licence. First stable version created by Fabounet.
Many thanks to TuxFamily for the web Hosting and Mav for the domain name.