• [^] # Re: scons pas bien

    Posté par (site web personnel) . En réponse au journal scons 1.0. Évalué à 4.

    C'est la où ça coince pour moi : les projets doivent être utilisables car je diffuse les fichiers projets, très utilisés.

    Oui, cmake est non seulement un générateur de projets mais il ne faut pas se leurrer, il est nécessaire à toute personne désirant bosser sérieusement sur le projet.
    Pour moi, c'est très loin d'être rédhibitoire vu la simplicité extrême de l'installation et de l'utilisation de cmake. (sous windows, l'installeur se charge même d'inscrire ce qu'il faut dans les variables d'environnement (comme le PATH) à ta place)
    De toute façon, c'est illogique et fastidieux de distribuer par exemple une solution MSVC générée à partir de cmake à un développeur, attendre un patch de sa part et ré-intégrer les éventuels nouveaux fichiers (ou optimisations) de cette solution dans le(s) CMakeLists.txt.
    => Tout le monde bosse sur les CMakeLists.txt, les .sln/.vcproj ne sont plus jamais modifiés (en tout cas, pas de façon pérenne, juste pour des petits tests) mais juste utilisés, c'est ainsi que se conçoit l'utilisation de cmake. Et le traitement platform-specific doit être réalisé en amont dans les CMakeLists.txt grâce aux directives adéquates.
    Pour le fichier CMakeLists.txt par répertoire source, bien sûr que non ce n'est pas nécessaire. La pratique qu'on trouve le plus souvent, c'est de créer un CMakeLists.txt par projet (une lib statique, dynamique, une application, un plugin, etc) et il est de toute façon toujours possible de référencer les sources de façon relative par rapport à la location du CMakeLists.txt.
    Bref, vous l'avez compris, je suis fan :). Surtout que cmake se bonifie vraiment avec le temps, on trouve le support de plus en plus de bibliothèques tierces dans share/modules.
    Le seul reproche que j'ai à lui faire, c'est sa documentation qui manque d'exemples et souvent d'explications.