Рекомендации по обработке CFLAGS в сценариях configure?

Я не поклонник autoconf, но в интересах принципа наименьшего удивления я пытаюсь сделать мои скрипты configure (non-autoconf) максимально внимательными к тому, что пользователи ожидают от autoconf-based построить систему. Стандарты кодирования GNU на самом деле довольно разумны в этой теме и явно указывают на возможность не использовать autoconf/automake, но предоставляют совместимый интерфейс по-другому:

https://www.gnu.org/prep/standards/standards.html#Configuration

Одна проблема, я не могу найти никакого хорошего описания, однако, как лучше всего обрабатывать CFLAGS. Мне ясно, что любые существенные флаги (например, -I$(srcdir)/inc), которые не являются ни одной из бизнес-пользователей, не принадлежат CFLAGS ни в configure script, ни в make файле, поскольку переопределение их полностью разрушит сборку. Поэтому я либо жестко закодирован в make файле, либо (если они требуют некоторого обнаружения) поместил логику обнаружения в configure, но передал их через отдельную переменную make вместо CFLAGS, поэтому они не будут переопределены.

Тем не менее, я все еще не понимаю, как справляться с лучшими, это необязательные вещи, такие как уровни/параметры оптимизации, флаги предупреждений, отладка и т.д. Если флаги, включенные такими вещами, как --enable-debug или --enable-warnings, добавляются в CFLAGS или переданы в какой-либо другой переменной make? Что делать, если они конфликтуют с флагами уже в пользовательском CFLAGS?

Я могу видеть, где для большого количества проектов ответ может быть просто "не возиться с этим вообще и позволить пользователю выбирать их CFLAGS", но некоторые из моих случаев использования - это проекты, в которых пользовательская база обычно интересуется настройкой готовых и отладочных конфигураций.

Изменить: Еще одна проблема, которую я забыл: когда дело доходит до обнаружения и автоматического использования определенных CFLAGS, которые не являются существенными, но предпочтительными, это должно быть сделано, только если пользователь оставил CFLAGS пустым в окружающей среды или всегда?

Ответ 1

Если вы хотите обрабатывать аргумент типа --enable-warnings, у вас есть много работы. Если вы хотите, чтобы это было просто, вы можете добавить этот аргумент как

CFLAGS="$CFLAGS -Wall -Wextra"; CPPFLAGS="$CPPFLAGS -DWARNINGS"

в вашей конфигурации script, но это фактически открывает большую банку червей. Являются ли эти параметры признаны всеми компиляторами или вы предполагаете, что ваш пользователь использует компилятор, который распознает эти параметры и для чего они делают то, что вы хотите? Вероятно, вам нужно обернуть это задание в другую проверку для набора компиляторов, о которых вы знаете. Или вам нужно проверить, что компилятор, используемый пользователем, по крайней мере, не выдает ошибок при передаче этих флагов (возможно, пользователь уже установил -Wsome в CFLAGS, и компилятор будет ошибочно ошибочно аргументировать - Стена.) Те же проблемы относятся к --enable-debug. Кажется вполне разумным ответить на --enable-debug, добавив -DEBUG в CPPFLAGS, поэтому пользователю не нужно проверять ваш источник, чтобы определить, включена ли отладка через -DEBUG, а не -DDEBUG, но вы не можете предсказать все ситуации и как правило, лучше ошибаться на стороне осторожности, а не делать такие вещи.

Если вы хотите, чтобы ваши пользователи имели "готовые оптимизированные и отладочные конфигурации", настройка script для проекта - это неправильное место для этого. Храните конфигурацию просто, и вы используете для этого такие системы управления пакетами, как pkgsrc. Если вы хотите, чтобы ваш дистрибутивный tarball имел некоторые из этих функций, предоставляйте набор сценариев (возможно, автоматически определяемый configure script после обнаружения платформы, но предоставляющий возможность переопределить эту функцию) для общих платформ, которые выполняют назначения для пользователь и, таким образом, обеспечивают требуемую функциональность. Но сохраните конфигурацию script сам bare-bones.

Ответ 2

Было бы достаточно здраво, чтобы пользователь ожидал, что придется бороться с вещами при предоставлении пользовательских флагов. CFLAGS может быть добавлено, CPPFLAGS может быть добавлено (параметры пути поиска заголовка смотрят на первый путь, тогда как оптимизаторы и директивы компилятора смотрят на последние параметры (вернее, они переопределяют предыдущие параметры))

--enable-debug и, возможно, другие директивы командной строки, предоставленные configure script, не только должны изменять параметры компилятора, но также иметь возможность изменять вещи внутри источника (возможно, например, переопределять встроенные макросы для фактических функций), поэтому их использование несколько отличается.

В заключение укажите пользовательский указатель CPPFLAGS, указанный пользователем CFLAGS; любой параметр конфигурации script может быть добавлен или добавлен в зависимости от контекста.