Il y a quelque temps, j'ai démarré une grande bibliothèque d'en-têtes en C++ 1x en utilisant XCode. La disposition actuelle de la bibliothèque est () quelque chose comme (sortie partielle de ls -R sponf
)
sponf/sponf:
ancestors sponf.h sponf_utilities.h
categories sponf_children.h utilities
children sponf_macros.h
sponf/sponf/ancestors:
function.h meter.h set.h simulation.h
sponf/sponf/categories:
free_space.h prng.h random_distribution.h series.h
sponf/sponf/children:
distributions histogram.h random simulations
meters numeric series spaces
sponf/sponf/children/distributions:
arcsine_der.h exponential.h
box_muller.h uniform.h
sponf/sponf/children/meters:
accumulator.h timer.h
#... other subdirs of 'children' ...
sponf/sponf/utilities:
common_math.h limits.h string_const.h
#... other directories ...
Je voulais porter ce projet sur CLion, ce qui semble être un très bon IDE (basé sur le même IDE AndroidStudio), mais certains problèmes me sont apparus.
J'ai essayé ce petit programme comme test:
#include <iostream>
#include <sponf/sponf.h>
using namespace std;
int main() {
using space = sponf::spaces::euclidean_free_space<double, 3>;
sponf::simulations::random_walk<space> rw;
rw.step(1);
std::cout << rw.position.value << std::endl;
return 0;
}
Le programme compile et fonctionne bien. Cependant, CLion ne reconnaît pas l’espace de noms spaces
(déclaré dans l’un des fichiers enfants), ni l’espace de noms simulations
; ils sont tous deux marqués en rouge et je ne peux pas inspecter leur contenu, ni naviguer vers leurs définitions par ⌘-cliquer, etc etc ...
En regardant dans "sponf.h"
on trouve
#ifndef sponf_h
#define sponf_h
/* The classes below are exported */
#pragma GCC visibility Push(default)
// include some of the standard library files
// ...
#include <Eigen/Eigen>
#include "sponf_macros.h"
#include "sponf_utilities.h"
#include "sponf_children.h"
#pragma GCC visibility pop
#endif
tandis que dans "sponf_children.h"
(qui est situé au niveau supérieur, à côté de "sponf.h"
), nous trouvons
#ifndef sponf_locp_sponf_children_h
#define sponf_locp_sponf_children_h
namespace sponf {
// include some of the children
// ...
#include "children/spaces/euclidean_free_space.h"
#include "children/simulations/random_walk.h"
// include remaining children
// ...
}
#endif
Chaque en-tête "enfant" inclura alors son en-tête "ancêtre" ou "catégorie" correspondant (qui définit la superclasse de "l'enfant" lui-même).
Malgré la prédiction d'auto-complétion, qui trouve facilement tous les sous-répertoires et les en-têtes, toutes les directives include de ce dernier fichier sont marquées en rouge et ⌘-cliquer sur l'un d'eux conduit à un message contextuel
Impossible de trouver la déclaration à laquelle se rendre
tandis que le ruban droit de l'éditeur signale de nombreuses erreurs comme
',' ou) attendu
) attendu
Déclarateur attendu
Type attendu
Manquant ;
Symbole inattendu
qui ne sont pas les mêmes pour chaque instruction include (chacune génère de 2 à toutes ces erreurs).
D'autre part, CLion est parfaitement capable de trouver tous les en-têtes Eigen
, qui ont à peu près la même structure!
J'ai mis les deux bibliothèques dans /opt/local/include
et modifié CMakeLists.txt
en conséquence
cmake_minimum_required(VERSION 2.8.4)
project(sponf)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++11")
include_directories(/opt/local/include/sponf /opt/local/include/eigen3)
set(SOURCE_FILES main.cpp)
add_executable(sponf ${SOURCE_FILES})
Pourquoi CLion ne parvient-il pas à analyser correctement la structure du projet? XCode, après avoir inclus /opt/local/include/sponf
et /opt/local/include/eigen3
dans le HEADER_SEARCH_PATHS
env. variable du projet, est capable de trouver n’importe quel en-tête lors de la compilation du même programme exact.
Y a-t-il autre chose que j'ai besoin de savoir? Est-ce que je me trompe ou est-ce que CLion n'est pas encore mature et qu'il ne s'agit que d'un bogue? C’est ma première approche de la chaîne d’outils CLion et CMake. Toute information à ce sujet sera donc grandement appréciée!
Désolé pour la très longue question, je n'ai pas réussi à la réduire davantage ... Merci d'avance les gars, à bientôt!
Voici ce que j'ai fait dans Windows avec cigwin64. Je voulais utiliser la bibliothèque Eigen include dans mon projet. La bibliothèque Eigen est une place dans/usr/include/eigen, puis édité CMakeLists.txt et ajouté
include_directories("/usr/include/eigen")
dans ça. Maintenant, CLion peut trouver tous les fichiers sources dans eigen lib. Peut-être que ce que vous vouliez aussi.
La rétrogradation à Clion 2016.1.4 corrige le problème