Inclusion de "fichier.h" rangé dans un sous dossier du projet

International Français
1

bonjour,

j'ai un projet qui fait appel à de multiples inclusion de fichier.h
Pour structurer au mieux le dossier du projet, j'aimerais placer ces fichiers dans différents sous-dossiers.
Je sais qu'il est possible de le faire avec GCC en utilisant ce genre d'écriture:

#include "../lib/gromain.h"

avec "gromain.h" dans le sous-dossier "lib" lui même dans le dossier du projet.

malheureusement, ça ne semble pas fonctionner avec avr-gcc, à moins que ce l'IDE qui ne le supporte pas.

Une idée?

Merci d'avance

Gromain

2

Bonjour,

C'est tout à fait faisable avec avr-gcc aussi (je le fais). Je penche plutôt pour une subtilité de l'IDE Arduino.

3

SesechXP,

mon compteur de points pour me passer de l'IDE arduino est en train de s'incrémenter...
au passage, le code de mon projet compilé avec avr-gcc 4.5.3 (ubuntu 11.10) me pose problème, alors que tout est ok avec une version 4.3.5 (ubuntu 10.10) ! à moins que ce soit un problème de version de avr-libc.
Encore une subtilité...

Merci de ta réponse.

Gromain

4

si si, ça fonctionne avec l'IDE arduino, puisque c'est utilisé par exemple dans la lib SDcard :

dans SD/h :
#include <utility/SdFat.h>
#include <utility/SdFatUtil.h>

je pense que ton soucis vient plutot de la syntaxe

5

ok, les inclusions de fichiers stockés dans le dossier du compilateur fonctionnent #include <...>

Là, je souhaiterais la même chose mais avec les fichiers dans le dossier du projet.
Mais tu m'as mis sur la voie: ça marche !!!

La solution: il faut mettre ces fichiers dans un dossier appelé "utility". Je peux ensuite les classer dans des sous-dossier de ce répertoire et les appeler simplement avec #include "monfichier.h"

Merci les gars !

Gromain

6

bon, j'ai parlé trop vite...
ça marchait sous windows, mais pas sous ubuntu :~

7

ben chez moi ça marche sous ubuntu, avec la 1.0

8

@Gromain59 : peux-tu donner une arborescence type ? Histoire de chercher une solution en bossant sur la même :wink:

9

bricofoy:
merci pour le test, je ne suis pas encore passé en version 1.0, mais il faudra bien un jour...

SesechXP:
arborescence type:

dossier "monprojet":

|[dossier_lib][dossier_lib1]
| |_[dossier_lib2]
|
|_monprojet.pde

10

ok je viens de comprendre ce qui se passe : voila la ligne d'appel de GCC que l'on peut obtenir en cochant la case "show verbose output" dans les pref de l'IDE 1.0 :

avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=100 -I/home/yann/arduino-1.0/hardware/arduino/cores/arduino -I/home/yann/arduino-1.0/hardware/arduino/variants/standard /tmp/build4840850446026298026.tmp/Datalogger_SD_RTC.cpp -o/tmp/build4840850446026298026.tmp/Datalogger_SD_RTC.cpp.o

on voit là dedans que ce n'est pas directement le PDE qui est compilé dans son dossier d'origine, mais une copie qui en est faite dans un dossier temporaire. Du coup le chemin relatif du .h par rapport au fichier pde, ben ça ne marche pas, forcément !! Pour que ça marche il faut donc mettre le chemin complet du fichier .h, c'est complètement débile, en fait.

#include "/home/yann/sketchbook/Datalogger_SD_RTC/include/Datalogger_SD_RTC.h"
ça ça marche. pas chiant, le truc. Et bonjour le merdier quand on copie un projet ailleurs...

Et le second truc idiot avec ce système, c'est que si dans le .h on veut appeler une lib, alors là aussi il faut fournir le chemin complet !! car sinon il ne la trouve pas ???

A trop vouloir simplifier les choses, finalement ça en devient inutilisable.....

11

je croyais que ça marchait, mais en fait c'est quand le .h est dans le même dossier que le PDE, pardon pour la fausse joie :stuck_out_tongue:
par contre je viens de comprendre ce qui se passe : voila la ligne d'appel de GCC que l'on peut obtenir en cochant la case "show verbose output" dans les pref de l'IDE 1.0 :

avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=100 -I/home/yann/arduino-1.0/hardware/arduino/cores/arduino -I/home/yann/arduino-1.0/hardware/arduino/variants/standard /tmp/build4840850446026298026.tmp/Datalogger_SD_RTC.cpp -o/tmp/build4840850446026298026.tmp/Datalogger_SD_RTC.cpp.o

on voit là dedans que ce n'est pas directement le PDE qui est compilé dans son dossier d'origine, mais une copie qui en est faite dans un dossier temporaire. Du coup le chemin relatif du .h par rapport au fichier pde, ben ça ne marche pas, forcément !! Pour que ça marche il faut donc mettre le chemin complet du fichier .h, c'est complètement débile, en fait.

Et le second truc idiot avec ce système, c'est que si dans le .h on veut appeler une lib, alors là aussi il faut fournir le chemin complet !! car sinon il ne la trouve pas ???

A trop vouloir simplifier les choses, finalement ça en devient inutilisable.....

EDIT : bon sang, même si le .h est à la racine du projet on ne peut pas appeler une lib dedans, il ne trouve pas le fichier !! là par contre je ne comprends plus...

EDIT2 : ok là aussi je viens de comprendre pourquoi ça foire en allant faire un tour dans le dossier temporaire... en fait l'IDE arduino copie dedans les librairies appelées depuis le .PDE, mais pas ce qui peut être appelé dans un .h différent ! donc forcément si les lib sont dans le .h, le compilateur ne trouve pas les lib dans le dossier de compilation et ça ne marche pas...

EDIT3 : ha non pardon, en fait il ne copie pas les lib mais il les inclus dans la ligne de commande du compilateur :

avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=100 -I/home/yann/arduino-1.0/hardware/arduino/cores/arduino -I/home/yann/arduino-1.0/hardware/arduino/variants/standard -I/home/yann/arduino-1.0/libraries/SD -I/home/yann/arduino-1.0/libraries/Wire -I/home/yann/sketchbook/libraries/DS1307 -I/home/yann/sketchbook/libraries/OneWire -I/home/yann/sketchbook/libraries/DallasTemperatureControl /tmp/build4840850446026298026.tmp/Datalogger_SD_RTC.cpp -o/tmp/build4840850446026298026.tmp/Datalogger_SD_RTC.cpp.o

à comparer avec le ligne de commande citée plus haut quand les libs sont dans le .h ........ là je crois que c'est isoluble, sauf à modifier l'IDE en profondeur ! ou alors juste modifier la ligne de commande de base du compilo pour include par défaut toutes les libs dispo, mais faut voir ensuite si il va les compiler quand même même si elles ne sont appelées nulle part ou pas... sinon la taille du programme va remplir la mémoire de l'arduino pour rien

12

merci bricofoy,

ceci explique cela...

je vais vraiment finir par abandonner l'IDE si ça continue :smiley:

13

en fait la solution c'est de développer tout ton soft dans une librairie, et de n'avoir dans ton PDE que l'inclusion de la lib et un appel de fonction pour lancer le prog :stuck_out_tongue:

au moins dans les lib ça se passe normalement avec des .cpp et .h ....

14

+1 avec Bricofoy, je ne vois pas d'autre solution avec l'IDE Arduino :~

15

J'utilise Code::Blocks avec toujours le soucis avec les bibliothèques Arduino en C++, donc je n'utilise pas pour le moment le core.a Arduino, ce qui m'oblige à réinventer la roue : c'est formateur mais pas efficace.
Je ne sais toujours pas si c'est moi qui ne sait pas configurer les bonnes options ou si c'est les bibliothèques Arduino qui sont mal compilés.

Sur le forum international "Other Hardware Development" j'ai pu lire qu'il existe depuis quelques semaines un plugin pour Eclipse qui permettrait d'utiliser le core.a Arduino et aussi une version modifiée de Code::Blocks utilisant le core.a Arduino.
Je n'ai encore testé ni l'un ni l'autre. Pas le temps, en retraite on commence trop de choses en même temps :grin:

PS: Sur Debian SID et Testing , donc sur la version à jour d'Ubuntu, le responsable du paquet est entré en relation avec le concepteur du plugin pour Eclipse, il a fait un nettoyage des paquets arduino (version 1.0xxx) et les retours semblent positifs.

Edit : avec le "search" du forum rechercher les messages écrits par Jantze pour le plugin éclipse