2006/8/4, dufy <[EMAIL PROTECTED]>:
OK pour moi.
Cool :)) Mais après réflexion, je vais sensiblement changer ma requête voir ci-après.
On 7/14/06, Erk <[EMAIL PROTECTED]> wrote: > Avec le passage imminent à CMake > (sauf contre-indication médicale) > j'aimerai en profiter pour faire un peu de ménage > dans exec et dégager la notion de "current". > > Dans ce que j'ai fait avec build CMake actuel on a: > > exec/<ARCH>/<BUILD_TYPE>/bin > exec/<ARCH>/<BUILD_TYPE>/lib
[...] CMake supporte très bien le "out of source build tree". C'est à dire que CMake permet de séparer les sources des fichiers produits par le système de build utilisé. Avec CMake on peut faire mkdir myproj-build cd myproj-build cmake /path/to/tsp_sources_tree make les binaires, libs etc... sont générés directement dans myproj-build/ donc on peut ensuite facilement faire: mkdir tsp-debug-build cd tsp-debug-build cmake $(TSP_BASE) make puis (build TSP optimisé) mkdir tsp-opt-build cd tsp-opt-build cmake $(TSP_BASE) -DCMAKE_BUILD_TYPE=Release make ou encore (build TSP for win32 using MinGW) mkdir tsp-mingw-win32-debug-build cd tsp-mingw-win32-debug-build cmake $(TSP_BASE) -G"MinGW Makefiles" make etc... Ensuite le répertoire de build se "souvient" des arguments passés à CMake la première fois et on peut faire (dans n'importe lequel de ces build tree) cd /path/to/my-build cmake . Du coup aller coller "comme avant" les fichiers générés dans les sources tsp/exec/.... est non seulement inutile mais contraire aux recommandations d'utilisation de CMake. Donc je reformule ma question: Etes-vous OK pour SUPPRIMER l'utilisation de tsp/exec à la faveur du build-tree CMake? A noter qu'il y a d'autres (bonnes raisons) pour lesquelles je vote personnellement OUI à la suppression de tsp/exec mais je ne les liste pas là pour ne pas rallonger le mail. -- Erk _______________________________________________ Tsp-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tsp-devel
