• [^] # Re: Gestionnaire de projets

    Posté par . En réponse au journal Retour aux sources. Évalué à 2.

    Utiliser -O3 par défaut serait une ânerie, ce niveau d'optim peut déclencher des bugs (je n'ai pas d'exemples précis en tête, cependant, mais une recherche devrait pouvoir te guider rapidement. Du côté du wiki de gentoo, peut-être?).

    Idem, "-DPLUMA_EXPORTS" n'à rien de standard.

    Générer des libs shared par défaut serait, encore, de bien mauvais goût, selon la taille, ça peut juste être un coup à générer du méchant bloatware (dans le cas de pluma, comme tout le monde l'aura lu dans le très concis exemple de VS, il y à 4 cibles: debug/release et share/static).

    Imposer des paths n'est pas non plus une bonne idée, j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions, et ça peut même varier selon le projet: par exemple pour une lib, séparer les include d'interface des include utilisés par le source est fréquent.
    Je ne parle même pas du cas ou le src contiens des sous-dossiers en fonction de l'interface utilisé... (aptitude est un exemple).

    D'ailleurs, je pense qu'il est largement faisable de faire ce que tu as fait en autant de lignes avec cmake, si tu as un template à inclure... je ne vois pas pourquoi ça le serait.
    Un truc genre (syntaxe à l'arrache):

    include( montemplate.cmake )
project( pluma )
build_library( pluma )

    Ne doit pas être infaisable. À ce niveau, je me demande(en tout cas on peut creer des fonctions) si on ne pourrait pas construire un template, ou plutôt une lib, qui permettrait d'écrire:

    include( montemplate.cmake )
build_library( pluma )

    Alors, ok, c'est pas en standard, mais bon, ça fait bien ce que tu demandes, avec encore moins d'infos "inutiles" que ton xml.