library - ¿Cómo evito que una inclusión citada busque el directorio del archivo fuente actual?

gcc include library

Question

gcc proporciona la opción -I- , para la cual los directorios -I que preceden a -I- se incluyen entre comillas ( #include "foo.h" ), y los directorios -I siguen a -I- se buscan entre corchetes ( #include <foo.h> ), así como también después de las otras para las #include <foo.h> .

-I- tiene otro efecto muy importante. Elimina el directorio del archivo de origen donde se encuentra el #include de la ruta de búsqueda predeterminada. Normalmente, una cita entre comillas siempre busca en el directorio del archivo fuente y lo busca antes de cualquier -I u otros directorios. -I- por -I- tanto, le permite especificar exactamente dónde ir para los archivos de inclusión citados en el orden que desee, eliminando esa ruta predeterminada que de otro modo tendría prioridad.

Así que suena como si respondiera a mi pregunta, ¿sí? No. Cuando uso -I- ahora, obtengo este nastygram:

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

El problema es que -iquote no elimina el directorio actual de la ruta de búsqueda. Todavía se busca siempre primero, sin importar lo que proporcione para -iquote .

Entonces, la pregunta es: ¿cómo obtengo el mismo efecto que -I- , sin usar -I- , que ha quedado en desuso y finalmente desaparecerá?

Elaboración:

Supongamos que los archivos se presentan de la siguiente manera:

srcdir/
    configure
    file1.c
    file2.c
    config.h

builddir/
    Makefile
    file1.o
    file2.o
    config.h
    libpudding.a

Por varias razones, no podemos eliminar config.h de srcdir (afectará el proceso de compilación en otras plataformas). Sin embargo, queremos incluir el config.h desde builddir con preferencia al zconf.h en srcdir .

Esto se puede lograr con la bandera de GCC -I- , pero parece imposible.

Pregunta actualizada:

Ok, parece que los desarrolladores de GNU CC están en desuso -I- , pero no proporcionaron una forma alternativa de lograr su funcionalidad. Entonces, mi pregunta actualizada es: ¿cuál es la forma más efectiva de llamar la atención de los desarrolladores para que haya una alta probabilidad de que cualquiera de los dos -I- esté descartado (lo que me parece más preferible, ya que es una forma bastante elegante) para manejar la especificación de la búsqueda, mucho más y mucho menos feo que -iquotexxx), o que se proporciona alguna forma de eliminar el directorio actual de una ruta de búsqueda de inclusión entre comillas?

Answer 1

Habiendo trabajado con las molestias de zconf.h en una zconf.h fuera del árbol, definitivamente volvería a su punto de que cuando una pregunta es muy complicada, a menudo es la pregunta incorrecta. Estás absolutamente en lo correcto. La pregunta correcta es por qué zconf.h existe en srcdir , cuando debería generarse desde zconf.h.in . Un archivo debe generarse siempre o nunca generarse para un conjunto dado de ajustes de configuración. Nunca debe proporcionarse y generarse en la misma compilación.

La mejor solución aquí es eliminar zconf.h del árbol de origen y generarlo siempre desde zconf.h.in tal como lo hace en la compilación CMake. Nunca he tenido claro por qué se hace de una manera para CMake y de otra para Make. Si el punto es que no tiene autoconf, y entonces va a usar un zconf.h para hacer, pero uno generado por CMake para CMake, entonces zconf.h.in como zconf.h.in ( lo que usted hace), y cópielo en el árbol de compilación en el Makefile.

Deshacerse del comportamiento extraño de -I- fue un buen movimiento. Tener varios archivos en la ruta de búsqueda a los que se hace referencia con el mismo nombre es extremadamente confuso y feo. Si el orden de búsqueda -I importa, entonces algo no está diseñado correctamente en su proyecto o en su compilación. Nunca debería tener que adivinar a qué se refiere #include "foo.h" . Definitivamente nunca debería estar en una situación en la que es fácil encontrarte editando el archivo incorrecto.

Aplaudo su trabajo mejorando la compilación de zlib. zlib ciertamente no es el paquete más difícil de compilar, pero tampoco es el más fácil (particularmente si necesitas el material contrib / minizip, que invariablemente lo hago).