ne pas afficher le path des headers

Bonjour,

J'ai un petit problème pas bien grave mais qui m'ennuit tous de même.

Je commence un projet en C++ et j'ai une structure de repertoire comme suis :

• projet/
  • src/
    • file1.cpp
    • file2.cpp
    • …
  • include/
    • file1.h
    • file2.h
    • …
  • build/
  • CMakeLists.txt
  • main.cpp

Ce que j'aimerais bien c'est de juste pouvoir faire des #include "file1.h" dans mes .cpp et non des #include "../include/file1.h"

Mais je comprend pas bien comment faire (et je suis sur que c'est possible car j'ai déjà utilisé des projets qui le faisait) J'ai beau bidouiller le "CMakeLists.txt" j'ai toujours une erreur à la compilation, il ne trouve pas les headers. (bien sur si je met le chemin dans les #include ca marche )

Pour le moment mon CMakeLists.txt est le plus simple possible

cmake_minimum_required(VERSION 2.8)

# projet

project(project)

# exécutable

file( GLOB_RECURSE all_files src/* include/*)

add_executable( main main.cpp ${all_files})

Bon j'ai pas trouvé grand chose de probant sur internet, tous ce que j'ai trouvé été a propos des librairies externe (comme boost). Et donc c’était des commandes pour modifier le comportement de #include <…> et non #include "…" (enfin d'apres ce que j'ai réussi à comprendre !)

Merci

Salut,

je ne connais pas CMakeList, mais si tu utilises g++ pour compiler en ligne de commande, utilises le paramètre -I qui te permet de préciser où chercher les headers.

Exemple :

• projet/
  • main.cpp
  • headers/
    • header.hpp

à compiler comme suit : g++ main.cpp -I headers.

Il faut utiliser la commande include_directories : http://www.cmake.org/cmake/help/v3.0/command/include_directories.html

1

include_directories(./include/)

Utiliser -I directement est une mauvaise idée, parce que même si ça fonctionnera pour la compilation, ça ne s'intègre pas forcément avec les EDIs derrière.

Par exemple, mon CMakeLists.txt est comme ça : https://github.com/alexandre-janniaux/bamboo-painter/blob/master/CMakeLists.txt

edit: je poste quand même, nah

OK donc en fait c'est juste que je suis pas foutu de modifier le nom de mes variables quand je change le nom du projet …

J'avais déjà une ligne include_directories(${PROJECT_SOURCE_DIR}/include/)mais avec le mauvais nom de projet… ok ça valait le coup de fouiller 3h pour chercher une solution compliqué

Merci !

PS : Du coup c'est quoi l'usage habituel pour ne pas avoir à se préoccuper des fichiers si il ne faut pas utiliser GLOB ? lister à la main ?

Je voie pas trop ce que ça change, car si on utilise GLOB il faut relancer cmake, si on ajoute à la mains il faut également relancer cmake non ?

lister à la main ?

Oui :aie: Mais d'un autre côté, ça te permet d'exclure/inclure dynamiquement des sources (pour s'adapter à la plate-forme, (dés)activer des modules, etc).

si on ajoute à la mains il faut également relancer cmake non ?

Non, moi je comprends de ce que j'ai cité que si le CMakeLists.txt n'est pas modifié (basé sur son mtime ?), le(s) Makefile (ou autre suivant le générateur utilisé), n'est pas modifié donc les sources compilées restent les mêmes (= pas prise en compte des sources ajoutées ou supprimées). Alors qu'en gérant la liste à la main, vu que ton CMakeLists.txt s'en trouve, de fait, modifié, il sait qu'il doit régénérer le Makefile (ou autre).

Pas essayé mais j'imagine que sinon il faut "touch"er le CMakeLists.txt pour lui forcer la main (à moins qu'il se base sur autre chose comme un hash/checksum).

Rien ne t'empeche d'utiliser glob. Même avec plusieurs systèmes, il suffit de s'arrêter à un niveau de profondeur, et de mettre les fichiers par système dans un dossier par système !

Je ne l'utilise pas parce que ca me permet de rajouter des fichiers que je ne veux pas compiler maintenant, mais c'est plus une fausse excuse qu'autre chose (c'est une mauvaise méthode pour avancer un projet).

ok merci pour vos réponses !

De toute manière c'est un petit projet personnel qui n'a pas à vocation d'être exportable ni rien. Mais bon c'est bon a savoir les soucis que peuvent procurer glob !

Le Cmake c’était plutôt pour m’épargner d’apprendre à faire un beau Makefile (et comme de plus en plus de truc utilise CMake, je suppose que ça va devenir la norme )