• [^] # Re: scons pas bien

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

    et quand libtool entre dans la danse t'es bon pour l'asile

    Ah, ça me rassure un peu, je pensais être seul bon pour l'asile à cause de libtool :).

    Et au final t'as un systeme de build très moyennement portable puisqu'il a une tonne de dépendances vers des outils unix (m4, sh, make, perl)

    Euh... Je fais tourner Libtool et compagnie (surtout le ./configure qui en résulte) sur *nix, MacOS X, Cygwin et MinGW quand même... Et j'ai "juste" un Projet MSVC2008 en plus (et est-ce que SCons ou CMake saveint le créer à ma place? Je vois bien un truc Visual Studio dans la FAQ de CMake mais sans indiquer la version, rien dans SCons.)

    Est-ce que SCons ou CMake ofont la même chose à la fin (un "script" tout en un à diffuser)? Pour SCons, est-ce que j'ai besoin de Python installé? (non, parce que ça c'est rédhibitoire, Python n'est pas partout surtout pas sur des *nix exotiques et embarqués, et surtout je me vois mal imposer Python à mes utilisateurs, pour le moment ils ont juste à faire un ./configure && ./install sans se soucier d'une dépendance de l'installateur.). Les ./configure ça prend de la place aussi (je doit avoir 100 Ko de code source, et 400 Ko de ./configure, c'est lourd), SCons m'allège le bousin? (place d'un interpréteur Python inclu si il le faut obligatoirement).

    Vous l'aurez compris, je ne comprend pas encore tout dans ce que peux faire ou pas SCons ou CMake, je cherche à comprendre jusqu'ou ça peut remplacer ma chaine de compilation actuelle qui compile partout mais qui est assez lourde à gérer.