Indicare percorso alternativo di una libreria

So che è possibile indicare un percorso diverso per la libreria usate nell’include, ma non conosco bene la sintassi:

#include <libreria.h> // libreria in directory “library”

#include “libreria.h” // libreria in directory diversa (forse quella dello sketch?)

ma vuoi avere la possibilitá che la libreria sia in uno o l' altro posto o chiedi i posti dove devono essere le librerie per le 2 possibilitá di sintassi del include? Ciao Uwe

Ciao Uwe...

entrambe le cose: voglio imparare bene come funziona l'include.

Forse questo può aiutarti a capire. http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html

Grazie Leo, ma avevo già letto la cosa.

Insomma, ho fatto delle prove, ma sembra che la cosa più semplice sia quella di inserire la libreria nella directory "libraries".

O forse mi sbaglio?

se usi
#include “asd”
il compilatore cerca nella cartella corrente (quindi quella dello sketch!) e poi in quelle <>

se usi <> cerca solo nelle cartelle predefinite (in ordine libraries, libraries nella cartella dell’IDE (Serial, Wire, etc…), librerie del compilatore)

C'e da aggiungere che l'ide Arduino in fase di compilazione le librerie le ficca tutte a spanello insieme, pertanto un include in un progetto Arduino non conterrà mai il path, ma solo il nome della libreria. La cosa importante da sapere è su quali percorsi e con che precedenza vengono cercate le librerie.

ah già, quindi tutto il discorso <> e “” viene a decadere perchè tanto arduino fa un bel minestone di tutto!

niki77: C'e da aggiungere che l'ide Arduino in fase di compilazione le librerie le ficca tutte a spanello insieme,

Vero. Basta aprire un progetto e compilarlo, e poi andare a vedere nella cartella temporanea che gran calderone è stato creato :stuck_out_tongue_closed_eyes:

ho già fatto la pull request per sistemare il fatto e rendere l'IDE compatibile con il vero C, il bello è che non ho praticamente mai visto librerie "custom" che usano la cartella "utility", e quindi il passaggio sarebbe trasparente all'utente finale, salvo rarissimi casi.

Invece ci sono 4 librerie standard dell'ide che bisogna aggiornare, ma anche in questo caso sono modifiche interne e quindi completamente trasparenti all'utente. Se volete rompere un pò le balle: https://github.com/arduino/Arduino/pull/116

Ciao lesto, hai effettuato le modifiche in oggetto? Io l'ho fatto già da tempo ed ho riscontrato che comunque continuando ad usarle dall'ide originale quest'utlimo continua a compilare regolarmente. Pensandoci bene mi è venuto pensato che questo comportamento però è un pò strano. Tu che dici?

cioè modificando gli include per usare le sottocartelle la compilazione va a buon fine? questa è black magic :) non so, se mi dici c he è così provo a darci un'occhiata.

Esattamente, come ti hod etto tempo fà, io uso eclipse al momento per arduino, e ho dovuto CORREGGERE i puntamenti degli include di alcune librerie, perchè sennò non compilava (ovviamente). Il punto è che mi sono accorto che compilando nuovamente i vecchi progetti nell'ide originale (che utilizza le librerie con gli include modificati) queste vengono compilate correttamente. Comunque ho notato che a seguito di compilazione su ide originale, nella cartella temporanea (.build) vengono incluse come al solito le librerie del core a spanello e vengono incluse anche le librerie esterne compilate (tipo ethernet eeprom e spi) con tutta la loro cartellina mantenendo la struttura originale. Chizza che casso di ragionamenti fà l'ide in questo caso :grin: Mistero della fede!

leo72: Vero. Basta aprire un progetto e compilarlo, e poi andare a vedere nella cartella temporanea che gran calderone è stato creato :stuck_out_tongue_closed_eyes:

Nella cartella temporanea ci vanno a finire tutti gli stadi intermedi della compilazione, non c'è nulla di strano, tutti i compilatori usano una cartella d'appoggio per questa cosa oppure lo fanno nella cartella del progetto se non è stato specificata una cartella dedicata.

I file intermedi è normale, ma in questo caso ci ficca pure i sorgenti del core. Manon è questo il problema , quello che non si capisce è come fà a compilare indistintamente le librerie esterne sia esse abbiano gli include in formato originale (cosi come rilasciate da arduino) sia con gli include modificati(con percorsi relativi corretti).

niki77: I file intermedi è normale, ma in questo caso ci ficca pure i sorgenti del core,

No ci mette solo gli obj, e gli .elf, dei vari sorgenti usati durante la compilazione, ed è normale che sia così, forse ti fai ingannare dal fatto che vedi i nomi scritti come miofile.cpp.o .

quello che non si capisce è come fà a compilare indistintamente le librerie esterne sia esse abbiano gli include in formato originale (cosi come rilasciate da arduino) sia con gli include modificati(con percorsi relativi corretti).

Perchè l'IDE fa un override delle impostazioni di defult del compilatore e specifica lui i percorsi da usare.

L'IDE fa un gran bel casino. Compilando un programma ti ritrovi i sorgenti .cpp tutti copiati nella cartella /build, poi crea una cartella per ogni libreria inclusa, dentro ci mette una cartella /utility e dentro... non ci sono né header né i file cpp della libreria! :stuck_out_tongue_closed_eyes:

astrobeed:

niki77: I file intermedi è normale, ma in questo caso ci ficca pure i sorgenti del core,

No ci mette solo gli obj, e gli .elf, dei vari sorgenti usati durante la compilazione, ed è normale che sia così, forse ti fai ingannare dal fatto che vedi i nomi scritti come miofile.cpp.o .

nono, copia i sorgenti veri e propri in .cpp e .h, li puoi aprire e modificare (tra l'altro se vedi la issue che ho postato vedi che le istruzioni sono proprio di COPIA dei file e preparazione dell'elenco di path da dare al compilatore), in oltre prima di fare questa copia ha già letto l'INO e copia-incollato in un apposito cpp. quindi a quel punto nella cartella temp di build hai i sorgenti pronti, viene chiamato avr-gcc e poi avrdude

lesto: nono, copia i sorgenti veri e propri in .cpp e .h, li puoi aprire e modificare

strano, da me su IDE 1.0.2 per Windows (anche nel 1.0.1) nel log di compilazione dice

avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=102 -ID:\Programmi\Arduino\arduino-1.0.2\hardware\arduino\cores\arduino -ID:\Programmi\Arduino\arduino-1.0.2\hardware\arduino\variants\standard -ID:\Programmi\Arduino\arduino-1.0.2\libraries\Wire -ID:\Dropbox\Progetti\Arduino\Sketchbook\libraries\DS1307new -ID:\Dropbox\Progetti\Arduino\Sketchbook\libraries\LedControl -ID:\Programmi\Arduino\arduino-1.0.2\libraries\Wire\utility D:\Programmi\Arduino\arduino-1.0.2\libraries\Wire\Wire.cpp -o C:\Users\Daniele\AppData\Local\Temp\build5837474537041180748.tmp\Wire\Wire.cpp.o

e così per tutte le lib e per il core, infatti nella cartella temporanea nnon c'è traccia dei sorgenti, apparte quello dello sketch generato dall'ide ovviamente.

hai ragione, non copia i sorgenti delle librerie ma solo i sorgenti contenuti nella cartella dello sketch (tranne l'INO a cui viene aggiunto un #include "Arduino.h" e rinominato in .cpp