Comment empêcher une inclusion citée d’effectuer une recherche dans le répertoire du fichier source actuel?

gcc fournit l’option -I- , pour laquelle les répertoires -I précédant -I- sont recherchés pour les inclus cités ( #include "foo.h" ), et les répertoires -I après le -I- sont recherchés pour les inclus entre crochets ( #include ), ainsi qu’après les autres pour les #include citées.

-I- a un autre effet très important. Il supprime le répertoire du fichier source dans lequel se trouve #include du chemin de recherche par défaut. Normalement, une inclusion citée recherche toujours le répertoire du fichier source et le recherche avant tout répertoire -I ou autre. -I- vous permet donc de spécifier exactement où aller pour les fichiers d’inclusion cités dans l’ordre de votre choix, en supprimant le chemin par défaut qui aurait autrement priorité.

On dirait que j’ai répondu à ma question, oui? Non, quand j’utilise -I- maintenant, je reçois ce nastygram:

 cc1: note: obsolete option -I- used, please use -iquote instead

Le problème est que -iquote ne supprime pas le répertoire en cours du chemin de recherche. C’est toujours toujours la première recherche, peu importe ce que je fournis à -iquote .

La question est donc de savoir comment obtenir le même effet que -I- , sans utiliser -I- , qui est obsolète et finira par disparaître.

Élaboration:

Supposons que les fichiers sont disposés comme suit:

 srcdir/ configure file1.c file2.c config.h builddir/ Makefile file1.o file2.o config.h libpudding.a

Pour diverses raisons, nous ne pouvons pas supprimer config.h de srcdir (cela aura un impact sur le processus de construction sur d’autres plateformes). Cependant, nous voulons inclure le config.h de builddir de préférence au zconf.h dans srcdir .

Ceci peut être accompli avec le drapeau -I- de GCC, mais cela semble autrement impossible.

Question mise à jour:

Ok, il semble que les développeurs de GNU CC -I- obsolètes -I- , mais n’ont pas fourni d’autre moyen de réaliser ses fonctionnalités. La question que je me pose est donc la suivante: quel est le moyen le plus efficace d’attirer l’attention des développeurs sur cette question, de sorte qu’il existe une forte probabilité que l’un ou l’ -I- (I) ne soit pas -I- (ce que je préférerais, car c’est un moyen assez élégant gérer la spécification de la recherche, beaucoup plus et beaucoup moins laide que -iquotexxx), ou qu’un moyen soit fourni pour supprimer le répertoire en cours d’un chemin de recherche include cité?

Ayant travaillé avec les désagréments de zconf.h dans une version hors arbre, je reviendrais sans hésiter à ce que vous zconf.h quand une question est extrêmement délicate, c’est souvent la mauvaise question. Vous avez absolument raison. La bonne question est de savoir pourquoi zconf.h existe dans srcdir , alors qu’il devrait être généré à partir de zconf.h.in . Un fichier doit toujours être généré ou ne jamais être généré pour un ensemble donné de parameters de configuration. Il ne devrait jamais être à la fois fourni et généré dans la même version.

La meilleure solution ici est de supprimer zconf.h de l’arborescence source et de toujours la générer à partir de zconf.h.in exactement comme vous le feriez dans la construction CMake. Je n’ai jamais compris pourquoi cela se faisait d’une manière pour CMake et d’une autre pour Make. Si le fait est que vous n’avez pas autoconf et que vous allez donc utiliser un zconf.h pré-construit pour make, mais un généré par CMake pour CMake, zconf.h.in le zconf.h.in sous le nom zconf.h.in ( que vous faites) et copiez-le dans l’arbre de compilation du Makefile.

Se débarrasser du comportement bizarre de -I- était un bon geste. Avoir plusieurs fichiers dans le chemin de recherche qui sont référencés avec le même nom est extrêmement déroutant et moche. Si l’ordre de recherche est important, quelque chose n’est pas conçu correctement dans votre projet ou dans votre construction. Je ne devrais jamais avoir à deviner à quoi #include "foo.h" fait référence. Je ne devrais certainement jamais être dans une situation où il est facile de se retrouver à éditer le mauvais fichier.

J’applaudis votre travail d’amélioration de la construction de zlib. zlib n’est certainement pas le paquet le plus difficile à construire, mais ce n’est certainement pas le plus facile non plus (particulièrement si vous avez besoin du matériel consortingb / minizip, ce que je fais toujours).