web-dev-qa-db-fra.com

CLion ne résout pas les en-têtes de la bibliothèque externe

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.

Petit programme de test

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 ...

Parties pertinentes de la bibliothèque

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).

La réaction de CLion

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!

11
gianluca

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.

10
GPrathap

La rétrogradation à Clion 2016.1.4 corrige le problème

0
fire1