Include de fichier - Page 1

Systeme:
Linux + gcc (Surement valable sur tout unix)

Etat:
J'ai deux fichiers include :
/usr/include/toto.h
et
/usr/local/include/toto.h

But:
Faire qu'un fichier t.c contenant #include "toto.h" inclut la version de /usr/include et pas celle de /usr/local/include.
J'ai essayé avec
gcc -I/usr/include t.c -E
gcc -I/usr/local/../include t.c -E
rien n'y fait. J'inclus toujours celle de /usr/local/include.

Question:
Comment faire ?

Hmm ça semble logique que ça prenne toujours la version du fichier dans "local" quand elle existe, et tout ce que tu fais consiste juste à spécifier à GCC avec -I des répertoires qu'il connaît déjà, donc c'est sans effet sur le résultat. Il te faudrait plutôt l'option inverse, celle qui exclut un répertoire
D'après la documentation, tu peux utiliser -nostdinc pour ne pas inclure automatiquement les répertoires systèmes, ce qui à priori devrait te permettre de spécifier manuellement les répertoires que tu veux utiliser (et leur ordre) lors du préprocessing. Mais c'est peut-être peu crade comme méthode.

Je n'aime pas du tout cette solution car elle oblige à connaître tous les répertoires systèmes d'une machine, et je suis sûr d'en oublier avec la libc + gcc (il y en a partout !)
J'ai la solution de recopier les .h que l'on désire en local et de faire de ce répertoire local un répertoire d'include.
Mais c'est moche !

#include "/usr/include/toto.h" ?

mv /usr/local/include/toto.h toto.h.org
cp /usr/include/toto.h /usr/local/include/
gcc [...]
mv /usr/local/include/toto.h.org toto.h

Comment ça c'est pas joli ? Moi ça m'irait très bien, mais c'est sûrement tout sauf académique.

./4 > J'ai hésité à proposer celle là mais je me suis dit que c'était une pratique de programmation crade
Mais tant qu'à faire j'en ai une mieux

sudo mv /usr/include /usr/include.real
sudo mv /usr/local/include /usr/local/include.real
sudo ln -s /usr/include.real /usr/local/include
sudo ln -s /usr/local/include.real /usr/lnclude

(Mouahaha)
Enfin sinon l'idée en ./3 de recopier en local est sans doute le meilleur compromis. Mais si jamais c'est pour avoir une version particulière d'une lib il vaudrait mieux inclure la lib elle-même dans le projet à compiler je pense...
Enfin je suis malgré tout pas certain de bien cerner le problème, et si tu veux vraiment tout ignorer de /usr/local il y a forcément moyen de redéfinir temporairement les valeurs par défaut du répertoire d'include. (d'ailleurs ça serait pas bêtement une variable shell $INCLUDE par hasard ?)

Oui, certes. Mais sans toucher le code source si possible.
Et sans avoir les droits root.
Et je n'ai aucune variable d'environnement.

Le problème est de fournir à l'utilisateur la possibilité de spécifier où se trouve sa lib.
Le problème est que s'il spécifie /usr alors ca ne fait rien puisqu'il prend /usr/local/ en priorité.

Ca parlait que si /usr/local/include est prioritaire pour les include, /usr/local/lib n'est pas prioritaire pour les librairies (/usr/lib est toujours prioritaire). Bonjour le sac de noeuds...

Il y a quelque chose que je ne comprends pas... si les deux toto.h ne sont pas compatibles l'une/l'autre (que ça soit pour des problèmes de version ou parce que les deux font des choses totalement différentes), pourquoi ont-elles le même nom ?
Et s'il s'agit de deux versions différente, il me semblait que, dans le monde Linux, le fichier avait un nom avec un n° de version, et que le nom générique n'était qu'un lien symbolique vers le fichier qu'on voulait... non ? et dans ce cas-là, on pourrait faite un include sur toto2.45.h directement si c'est cette version qu'on veut spécifiquement...

Nil (./8) :
Il y a quelque chose que je ne comprends pas... si les deux toto.h ne sont pas compatibles l'une/l'autre (que ça soit pour des problèmes de version ou parce que les deux font des choses totalement différentes), pourquoi ont-elles le même nom ?

Deux versions différentes.

Nil (./8) :
Et s'il s'agit de deux versions différente, il me semblait que, dans le monde Linux, le fichier avait un nom avec un n° de version, et que le nom générique n'était qu'un lien symbolique vers le fichier qu'on voulait... non ? et dans ce cas-là, on pourrait faite un include sur toto2.45.h directement si c'est cette version qu'on veut spécifiquement...

Seules les libraries dynamiques compilées ont un tel versionning (les .so)
Pas les .h (ni les .a d'ailleurs).

Ok... c'est un peu dommage, non ?

Si.

En meme temps utiliser deux version différentes et incompatible de la meme lib dans un meme programme ? c'est pas un peu pas normal?

(Il ne l'utilise pas dans le même programme, il a les deux sur un même système, à deux endroits différents)

Merci .
C'est exactement ce que je voulais.

Pour savoir c'est quel distrib que tu utilise ?
Car il ne devrais pas mettre un repertoire non-system dans la liste par defaut.

debian, mais c'est vrai sur tout linux, bsd, unix.
/usr/local/include est un répertoire système; et il est prioritaire sur /usr/include.

Pas sur mon FreeBSD

elbarto@maetel> cat /usr/include/toto.h
cat: /usr/include/toto.h: No such file or directory
elbarto@maetel> cat /usr/local/include/toto.h
#define TOTO "/usr/local/include/toto.h"
elbarto@maetel> cat main.c
#include <stdio.h>
#include <toto.h>

int
main()
{
printf("%s\n", TOTO);
}
elbarto@maetel> gcc main.c
main.c:2:18: error: toto.h: No such file or directory
main.c: In function 'main':
main.c:7: error: 'TOTO' undeclared (first use in this function)
main.c:7: error: (Each undeclared identifier is reported only once
main.c:7: error: for each function it appears in.)
elbarto@maetel>

elbarto@maetel> cat /usr/include/toto.h
#define TOTO "/usr/include/toto.h"
elbarto@maetel> cat /usr/local/include/toto.h
#define TOTO "/usr/local/include/toto.h"
elbarto@maetel> cat main.c
#include <stdio.h>
#include <toto.h>

int
main()
{
printf("%s\n", TOTO);
}
elbarto@maetel> gcc main.c
elbarto@maetel> ./a.out
/usr/include/toto.h
elbarto@maetel>

A oui. Je suis surpris. J'ai vérifié, et pourtant gcc est censé regarder dans /usr/local/include (mais pas les autres compilateurs C).
C'est peut être un patch spécifique à freebsd ?

Cfr http://gnu.april.org/software/automake/manual/standards/Directory-Variables.html

C'est surement propre a FreeBSD (et je pense a Open et Net aussi) vu que /usr/local/ est fait juste pour les ports/packages.
En tout cas c'est clairement moche de faire de /usr/local/include un repoertoire d'include par defaut ...