Как запретить поиск по каталогу в текущем исходном файле?

Question

GCC обеспечивает -I- вариант, для которого -I каталоги, предшествующие -I- ищутся для указанных включенных (#include "foo.h"), а также -I каталоги, следующие за -I- ищутся в скобках включает в себя (#include <foo.h>), а также после того, как другие для указанных включены.

-I- имеет еще один очень важный эффект. Он удаляет каталог исходного файла, который #include находится в пути поиска по умолчанию. Обычно включенное в кавычки всегда ищет каталог исходного файла и ищет его перед любым -I или другие каталоги. -I- поэтому позволяет вам точно указать, куда обращаться к указанным включаемым файлам в нужном вам порядке, удалив этот путь по умолчанию, который в противном случае имел бы приоритет.

Похоже, я ответил на мой вопрос, да? Нет, когда я использую -I- теперь я получаю эту настиграмму:

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

Проблема в том, что -iquote не удаляет текущий каталог из пути поиска. Сначала по-прежнему всегда выполняется поиск, независимо от того, что я предоставляю -iquote,

Вопрос в том, как получить тот же эффект, что и -I-, без использования -I-, который был объявлен устаревшим и в конечном итоге уйдет?

Разработка:

Предположим, файлы разложены следующим образом:

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

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

По разным причинам мы не можем удалить config.h от srcdir (это повлияет на процесс сборки на других платформах). Тем не менее, мы хотим включить config.h от builddir в предпочтении zconf.h в srcdir,

Это может быть достигнуто с помощью GCC -I- флаг, но кажется иначе невозможно.

Обновленный вопрос:

Хорошо, похоже, разработчики GNU CC устарели -I-, но не предоставили альтернативного способа достижения его функциональности. Итак, мой обновленный вопрос: каков наиболее эффективный способ довести это до сведения разработчиков, чтобы с высокой вероятностью -I- является устаревшим (что я бы посчитал наиболее предпочтительным, поскольку это довольно элегантный способ обработки задания поиска, гораздо более и менее уродливый, чем -iquotexxx), или что есть какой-то способ удаления текущего каталога из включенного в кавычки включения путь поиска?

Answer 1

Работая с раздражениями zconf.h в сборке "из дерева" я определенно вернусь к вашей точке зрения, что когда вопрос очень сложный, это часто неправильный вопрос. Вы абсолютно правы. Правильный вопрос - почему zconf.h существует в srcdir вообще, когда это должно быть сгенерировано из zconf.h.in, Файл должен либо всегда генерироваться, либо никогда не генерироваться для данного набора параметров конфигурации. Он никогда не должен предоставляться и генерироваться в одной сборке.

Лучшее решение здесь - удалить zconf.h из исходного дерева и всегда генерировать его из zconf.h.in так же, как вы делаете в сборке CMake. Мне никогда не было понятно, почему это сделано одним способом для CMake, а другим - для Make. Если дело в том, что у вас нет autoconf, и вы собираетесь использовать предустановленный zconf.h для make, но сгенерированный CMake для CMake, затем просто отправьте его как zconf.h.in (что вы делаете), и скопируйте его в дерево сборки в Makefile.

Избавление от странного поведения -I- был хороший ход. Наличие нескольких файлов в пути поиска, которые называются с одним и тем же именем, чрезвычайно запутанно и безобразно. Если -I порядок поиска имеет значение, тогда что-то не правильно спроектировано в вашем проекте или в вашей сборке. Я никогда не должен угадывать, что #include "foo.h" относится к. Я никогда не должен быть в ситуации, когда легко найти себя, редактирующего неправильный файл.

Я приветствую вашу работу по улучшению сборки zlib. zlib, конечно, не самый сложный пакет для сборки, но он, конечно, не самый простой (особенно если вам нужны материалы contrib / minizip, что я всегда и делаю).