Я не поклонник autoconf, но в интересах принципа наименьшего удивления я пытаюсь заставить мои (не -сценарии конфигурации autoconf )вести себя как максимально близко к тому, что пользователи ожидают от системы сборки на основе autoconf -. Стандарты кодирования GNU на самом деле довольно разумны в этой теме и явно упоминают возможность не использовать autoconf/automake, а предоставить совместимый интерфейс другим способом :
https://www.gnu.org/prep/standards/standards.html#Configuration
. обрабатывать CFLAGS. Мне ясно, что любые существенные флаги (вроде -I$(srcdir)/inc
), которые не относятся к делу пользователя, не относятся к CFLAGS ни в скрипте configure, ни в make-файле, поскольку их переопределение полностью нарушило бы строить. Так что я либо жестко -закодировал их в make-файле, либо (, если они требуют некоторого обнаружения, )поместил логику обнаружения в configure, но передал их через отдельную переменную make вместо CFLAGS, чтобы они не получить переопределение.
Однако мне все еще неясно, как лучше всего справиться с необязательными вещами, такими как уровни/параметры оптимизации, предупреждающие флаги,отладка и т. д. Должны ли флаги, включенные такими вещами, как --enable-debug
или --enable-warnings
, добавляться в CFLAGS
или передаваться в какую-либо другую переменную make? Что делать, если они конфликтуют с уже установленными пользователем -флагами CFLAGS
?
Я вижу, что для многих проектов ответ может быть просто «не связывайтесь с этим вообще и позвольте пользователю выбрать CFLAGS
свое», но некоторые из моих случаев использования — это проекты, в которых пользовательская база обычно заинтересован в том, чтобы -из -оптимизированных и отладочных конфигураций блока -.
Редактировать:Другая проблема, о которой я забыл :, когда речь идет об обнаружении и автоматическом использовании определенных CFLAGS, которые не являются обязательными, но предпочтительными, должно ли это быть сделано только в том случае, если пользователь оставил CFLAGS
пустым в среде, или всегда?