Reflexions sur l'archi de bbtk et des packages ---------------------------------------------- *STRUCTURE DU SOURCE TREE : --------------------------- La lib bbtk devrait être dans un rep à part entiere et chaque package de la distrib standard à part avec la même structure qu'un package utilisateur donc dans le rep racine des sources : data/ reste data/ creation rep "kernel" qui correspond au toolkit bbtk (lib+appli) kernel/src/ accueille src/kernel/ kernel/doc/ accueille doc/ kernel/installer/ accueille install/ kernel/cmake/ accueille cmake/ kernel/appli/ accueille appli/ creation rep packages/ qui acceuille chaque package de la distrib standard donc on aura : packages/std/ packages/wx/ etc. la structure de chaque package sera identique et identique à celle créée par bbCreatePackage pour les utilisateurs : A la racine des sources d'un package, je propose : src/ : sources (ce qui est actuellement en vrac dans /src/packages/std/ par ex.) doc/ : docs doc/bbdoc : rep pour creation de la doc du package par bbdoc (bbi à terme ? cf. ci-dessous) incluant les images si besoin doc/doxygen : doc doxygen bbs/ : scripts associés au package bbs/boxes bbs/appli cmake/ : fichiers cmake pour build/install * PROPOSITION : TOUT EST BLACK BOX ET PACKAGE ! ----------------------------------------------- A l'heure actuelle, du point de vue de l'utilisateur ou du createur de package, il y a : - les packages (libraries dynamiques) : - utilisés avec 'load' dans bbi - documentés : - en texte par 'help' dans bbi - en html par l'appli bbdoc (créée automatiquement lors du build) ces doc html sont référencées dans la doc html du package 'user' générée par 'graph' dans bbi (cf. ci-dessous) - les scripts (.bbs) : - utilisés avec 'include' dans bbi - documentés dans bbi par 'graph' qui documente le package 'user' Les scripts sont de deux types : - scripts de définition de complex boxes (define/endefine) - scripts d'appli (appli finale, de test, de demo, ...) Quand un utilisateur crée un nouveau package, ce package comprend à la fois une librarie dynamique (mais pas forcément, lire la suite ...) et des scripts (idem). Evidemment, il a envie : - que tout soit utilisable (donc que les chemins pour trouver sa lib et ses scripts soient connus de bbi). - que tout soit documenté et référençable (i.e. que les chemins pour référencer les doc de ses boites soient connus des autres packages). Je propose que : - les complex boxes définies par des scripts fassent partie à part entière du package (et de sa doc). Le mécanisme : 1) dans bbi, quand on définit une boite par 'define', on peut spécifier le package dans lequel elle va être placée, ex. : "define XOR std" dit que la boite XOR va dans le package std. Si ce package existe (déja loadé ou précédent 'define TOTO std') : ok l'insère. Sinon crée un nouveau package. => Déja mis en place et testé : cf scripts/test/testDefine.bbs Autre manière de faire : nouveaux mots-clés de bbi 'package/endpackage'. ex. : > package mypack > description "mon magnifique package" > author "foo@bar.com" > define mybox > ... > endefine > define mybox2 > ... > endefine > endpackage toutes les boites définies entre 'package/endpackage' vont dans le package (de la même manière que toutes les instances créés par 'new' entre 'define/endefine' vont dans la complex box courante). Ici, mybox et mybox2 seront dans mypack. Intérêt du bloc 'package/endpackage' : pouvoir documenter le package grace aux commandes standard 'description/author' ... (REM : finalement, le package 'user' et la boite 'workspace' peuvent se voir comme si au lancement, bbi exécutait les commandes "package user" puis "define workspace". Ca donne des idées pour avoir plusieurs workspaces...) Revenons maintenant aux scripts de complex boxes d'un package. 2) Un package utilisateur (ou standard bbtk) sera fournit **AVEC SON SCRIPT DE CHARGEMENT**. Par ex: std.bbs sera le script de chargement du package std. Exemple de contenu : # Load the 'atomic' boxes compiled in dyn lib : load std # Include the complex boxes scripts (which can load other packages...) include bbXOR ... Donc un utilisateur final mettra 'include std' dans ses scripts pour utiliser le package std (simple & complex boxes). INTERETS : A) Un utilisateur "lambda" utilisera toujours 'include' et ne verra que des boxes (simple ou complex). Un utilisateur "averti" pourra toujours ne loader que la lib ou n'inclure que certains scripts. B) La doc sera générée automatiquement via bbi. Il faut bêtement étendre la commande 'graph' pour que l'on puisse lui spécifier le nom du package dont on veut générer la doc (A l'heure actuelle graph cherche à documenter une boite du package 'user' ou une instance de 'workspace' et génère systématiquement la doc du package 'user' pour les références. En passant, voir aussi la réflexion ci-dessous sur les rôles ambigus des commandes help et graph). (La génération auto de la doc pourra se faire de manière quasiment identique à ce qui est fait à l'heure actuelle dans la macro BBTK_DOCUMENT_SCRIPTS de cmake/bbtkMacro.cmake : cela revient à lancer bbi sur un script du type : "include packagename" "graph packagename good-parameters") Donc plus d'appli bbdoc : tout est fait par bbi ! 3) Doc des appli (.bbs) : Idem que ci-dessus avec un script du type : >package std-demo > description "..." > define DemoXOR > include DemoXOR > endefine > define DemoAdd > include DemoAdd > endefine > ... >endpackage >graph std-demo [good-params] bbtk doit fournir aux utilisateurs une macro cmake pour générer ce type de script, les targets qui vont bien et l'installation de la doc au même endroit que toutes les autres doc, i.e. dans /packages//bbdoc. Ainsi toutes les refs croisées sont bonnes, on n'a que des packages documentés qui contiennent des boites (éventuellement d'applications)... Qu'en pensez-vous ? Finalement on aura la structure de package : PACK/src scripts/PACK.bbs scripts/boxes scripts/appli doc/boxes doc/appli * BUILD TREE ET INSTALLATION ---------------------------- Regle : On doit pouvoir utiliser bbtk ou n'importe quel package aussi bien en tant que package bbi (load/include) ou que librairie c++ (via cmake) à la fois dans le build tree et dans l'install tree. De plus, un install tree doit pouvoir être déplacé et rester utilisable modulo la spécification explicite du répertoire quand on lance cmake. En effet, FindBBTK.cmake ou Find[PackageName].cmake : 1) Ne sont pas installés dans l'install tree mais dans le rep de cmake donc ne sont pas copiés si on copie l'install tree (le Find*.cmake est le seul fichier installé hors install tree à ma connaissance. D'autres ? Ca poserait problème...) 2) Même si on installe "à la main" FindBBTK.cmake, le code qu'il contient ne recherche les install de bbtk qu'à des endroits "canoniques" donc si on pose l'install tree dans un endroit "exotique", il ne le trouvera pas et le chemin devra être entré manuellement. OK ? Structure des build/install trees : *Linux : PREFIX = build_tree_path, /usr, /usr/local PREFIX_SHARE = PREFIX/share/bbtk *Windows PREFIX = PREFIX_SHARE = build_tree_path, C:/ProgramFiles/bbtk PREFIX/bin : bbi, etc. PREFIX/lib : libbbtk.so, libbstd.so, etc. PREFIX/lib/bbtk : UseBBTK.cmake, etc. PREFIX/lib/bbstd : UseBBSTD.cmake, etc. PREFIX/include/bbtk : bbtkSystem.h, etc. PREFIX/include/bbstd : bbstdAdd.h, etc. PREFIX_SHARE/ PREFIX_SHARE/doc/bbtkWebSite bbtkDoxygen bbtkUsersGuide etc. PREFIX_SHARE/doc/bbdoc/std : index.html, *.png, etc. std-demo wx wx-demo USER_PACKAGE USER_PACKAGE-demo etc. PREFIX_SHARE/doc/doxygen/std : index.html, *.png, etc. wx USER_PACKAGE etc. PREFIX_SHARE/bbs/std/ std-demo wx etc.