[KDevelop] Script de formattage de source - Page 3

Je vais pas tarder à devoir ajouter Qt à un projet x-platform avec CMake, je sens que je vais me marrer

Oh cherche pas, t'es bien meilleur que moi d'une manière générale, tu m'aideras
C'est sûrement bien foutu pour celui qui a le feeling et du temps à y passer.

Folco (./60) :
Deux choses : J'arrive pas à me passer de link_directories, ce qui me parait normal pour le linker, et pourtant la doc dit que c'est rarement utilisé, target_link_libraries devant faire le boulot.

C'est parce que tu utilises Qt5Core, qui est un chemin relatif, à la place d'une variable comme ${Qt5Core_LIBRARIES} ou un target exporté comme Qt5::Core (ce qui dans ce cas revient au même, parce que ${Qt5Core_LIBRARIES} est défini comme ça: set(Qt5Core_LIBRARIES Qt5::Core) ).

L'avantage du target exporté, c'est que non seulement il te donne le bon chemin d'accès vers la bibliothèque, mais il rajoute aussi automatiquement les include_directories qu'il te faut, donc ce bloc est aussi redondant.

Ensuite, pour target_link_libraries, si je remplace Qt5Core par Qt5::Core ou autre variable sensée faire ce boulot, ça compile, ça linke, mais ça crashe instantanément au lancement de l'exécutable (j'ai pas de détails sur le crash).
Une idée ?

Tes DLLs sont-elles aussi trouvables en temps d'exécution? Windows regarde au moins dans le dossier de l'EXE et dans le PATH.

Bon, le problème se situe ailleurs...
Je compile en Debug. Avec Qt5Core, pas de souci, avec Qt5::Core, il me manque msvcp120d.dll et msvcrd.dll. C'est pas redistribuable, et pas contournable en mode debug. Je sais même pas où la trouver sur le site de MS :/
Bon, sinon, avec des dll chopées ici ou là (j'aime pas ça du tout), j'arrive à utiliser ta méthode c'est bien plus propre ainsi, merci beaucoup

Ya guère plus que SDL2 qui me fait suer, les devs de CMake et de SDL se rejetant depuis des années la responsabilité de fournir le modules Find* qui vont bien :/
Il y a bien ce genre de repos, mais c'est pas officiel : https://github.com/tcbrindle/sdl2-cmake-scripts

Ces DLL font normalement partit de l'installation de VisualStudio et potentiellement des SDK Windows

J'aurais pensé, oui, tellement ça semble évident qu'elles soint nécessaire au développement, et bien il faut croire que non

VisualStudio n'installe pas forcement toutes les version des DLLs de debugs (surtout les anciennes), tu utilise une version précompilé de Qt5? il ne disent pas avec quelle version de VS il a été compilé? Si ce n'est pas la meme version que celle que tu as, c'est normal

Voila je viens de regarder ya des verson prebuild pour VS2010, 2012 et 2013, mais pas de version 2015, j'imagine que tu as installé une version 2015 de Visual Studio, je pense que les versions des libs on changé comme souvent

Ca doit être ça, oui.

Folco (./64) :
Bon, le problème se situe ailleurs...
Je compile en Debug. Avec Qt5Core, pas de souci, avec Qt5::Core, il me manque msvcp120d.dll et msvcrd.dll. C'est pas redistribuable, et pas contournable en mode debug. Je sais même pas où la trouver sur le site de MS :/
Bon, sinon, avec des dll chopées ici ou là (j'aime pas ça du tout), j'arrive à utiliser ta méthode c'est bien plus propre ainsi, merci beaucoup

set(CMAKE_BUILD_TYPE RelWithDebInfo)ou alors tu règles ça dans la configuration de l'EDI. Le plus propre est du code comme ça:

if (NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
   set(CMAKE_BUILD_TYPE RelWithDebInfo)
   set(CMAKE_CONFIGURATION_TYPES ${CMAKE_BUILD_TYPE})
endif (NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)

comme ça, la valeur par défaut n'est mise que si on ne passe pas autre chose à CMake en ligne de commande.

Ya guère plus que SDL2 qui me fait suer, les devs de CMake et de SDL se rejetant depuis des années la responsabilité de fournir le modules Find* qui vont bien :/
Il y a bien ce genre de repos, mais c'est pas officiel : https://github.com/tcbrindle/sdl2-cmake-scripts

Un fichier Find*.cmake est facile à bundler, c'est souvent fait par les projets. Donc tu récupères le fichier de ce projet GitHub, tu le mets dans un dossier cmake de ton projet (la convention courante) (et tu rajoutes le fichier LICENSE.txt de CMake ou colles son contenu dans le fichier Find*.cmake – l'auteur du dépôt GitHub aurait dû faire ça, mais ne l'a visiblement pas fait). et tu mets tout au début de ton CMakeLists.txt (juste après le cmake_minimum_required qui devrait toujours être la première instruction d'un CMakeLists.txt moderne):
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

C'est ce que j'ai fait, mais j'ai mis set(CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")
En tout cas merci pour tout, je devrais bientôt avoir viré tout ce qui n'est pas portable de mon CMakeList.txt.

Folco (./71) :
C'est ce que j'ai fait, mais j'ai mis set(CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")

list(APPEND est plus propre parce que ça n'efface pas ce qui est déjà contenu dans la variable.

Et si tu es à la racine de ton projet, ${PROJECT_SOURCE_DIR} et ${CMAKE_CURRENT_SOURCE_DIR} sont le même chemin.

Yup, sur le principe tu as raison, j'ai bien pensé que c'était ce que faisait list(APPEND. Ceci dit, la doc dit que la variable que j'utilise est vide, et est spécifiquement faite pour être modifiée par mes soins, donc je ne pense pas qu'il y ait de risque. Mais ta technique est toujours bonne à prendre, ça me fait découvrir CMake petit à petit tout ça

En fait, la différence est surtout que ma ligne marche aussi dans un sous-dossier (utilisation de CMAKE_CURRENT_SOURCE_DIR, ajout à la liste déjà existante) alors que la tienne ne marche qu'à la racine du projet. Mais à la racine du projet, elles sont équivalentes.

Et bien voilà, ça donne ça :

cmake_minimum_required(VERSION 2.6)
project(imPG2)

set(CMAKE_BUILD_TYPE Debug)
#set(CMAKE_BUILD_TYPE Release)
#set(CMAKE_CXX_FLAGS_RELEASE "-DNDEBUG -O2")
#set(CMAKE_CXX_FLAGS_DEBUG "-O0 -g")
set(CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")

find_package(Qt5Core REQUIRED)
find_package(SDL2 REQUIRED)
find_package(SDL2_ttf REQUIRED)
find_package(SDL2_image REQUIRED)

add_executable(
    imPG2
    main.cpp
    Button.cpp
    Exception.cpp
    Game.cpp
    GameIntro.cpp
    GameState.cpp
    ResourceFactory.cpp
    )

include_directories(
    ${SDL2_INCLUDE_DIR}
    ${SDL2_TTF_INCLUDE_DIR}
    ${SDL2_IMAGE_INCLUDE_DIR}
    )

#target_compile_options(
#    imPG2
#    PUBLIC
#    -std=c++11
#    -fPIC
#    -Wall
#    -Wextra
#    )

target_link_libraries(
    imPG2
    Qt5::Core
    ${SDL2MAIN_LIBRARY}
    ${SDL2_LIBRARY}
    ${SDL2_TTF_LIBRARY}
    ${SDL2_IMAGE_LIBRARY}
    )

install(TARGETS imPG2 RUNTIME DESTINATION bin)

Plus qu'à voir comment gérer les switches. Peut-être le mode de compilation par défaut n'est pas bon non plus, et il faut que je me penche sur la différence entre le mode Debug et RelWithDebInfo. Mais c'est déjà pas mal, mon script est maintenant portable si on fait abstraction des switches, merci encore

Bon, KDevelop 4.7.3 et 5.0 bêta 2 \o/
https://www.kdevelop.org/news
Le backend clang dans la version 5 marche du tonnerre, c'est fluide, ça accélère le codage, et passer la souris sur le source fait apparaitre toutes les infos qu'on veut sur ce qui y est écrit, un vrai bonheur.

Au passage : le nouveau parseur clang powered roxe, parce que les macros sont pleinement supportées, donc tout ce qui est romcall de tigcclib est complété, suggéré, documenté en live :
Un énorme progrès. Un makefile, deux defines et trois includes plus loin, et on bénéficie de toute la puissance du soft pour coder sur TI, sous Windows, avec la splendeur de la rainbow coloration.
Juste un truc, l'attribut __stkparm__ n'est pas supporté, on attend un patch de Kevin