Как избежать переопределения VERSION, PACKAGE и т. д.

Я не видел вопросов, касающихся сборок GNU autoconf/automake, но я надеюсь, что хотя бы некоторые из вас знакомы с этим. Вот оно:

У меня есть проект (назовем его myproject), который включает в себя другой проект (поставщика). Проект поставщика — это автономный проект, поддерживаемый кем-то другим. Включение подобного проекта довольно просто, но в этом случае есть небольшая загвоздка: каждый проект генерирует свой config.h файл, каждый из которых определяет стандартные макросы, такие как ПАКЕТ, ВЕРСИЯ и т. д. Это означает, что во время сборки, когда вендор собирается, я получаю много ошибок, таких как это :

... warning: "VERSION" redefined
... warning: this is the location of the previous definition
... warning: "PACKAGE" redefined
... warning: this is the location of the previous definition

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


c linux unix autoconf automake
person Jason Day    schedule 10.08.2008    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Некоторые примечания:

  • вы не упомянули, как был включен config.h - с кавычками или угловыми скобками. Дополнительную информацию о разница. Короче говоря, config.h обычно включается в кавычки, а не в угловые скобки, и это должно заставить препроцессор предпочесть config.h из собственного каталога проекта (обычно это то, что вам нужно)
  • Вы говорите, что подпроект должен включать config.h включающего проекта. Обычно это совсем не то, что вам нужно. Подпроект является автономным, и его ПАКЕТ и ВЕРСИЯ должны быть такими же, как у этого подпроекта, а не у вас. Если вы включаете libxml, например, в свой проект xmlreader, вы все равно хотите, чтобы код libxml был скомпилирован с PACKAGE libxml и VERSION (какой бы ни была версия libxml).
  • Обычно большой ошибкой является включение config.h из общедоступных заголовков. config.h всегда является частным для вашего проекта или подпроекта и должен включаться только из файлов .c. Таким образом, если в документации вашего поставщика указано, что нужно включить их "vendor.h", а этот общедоступный заголовок каким-то образом включает config.h, то это - нет-нет. Точно так же, если ваш проект является библиотекой, не включайте config.h нигде из общедоступных заголовков.
person Thomas Vander Stichele    schedule 25.08.2008

arrow_upward
2
arrow_downward

Это определенно хак, но я обрабатываю автогенный config.h файл:

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h

Это терпимо в нашей среде сборки, но меня бы заинтересовал более чистый способ.

person David Joyner    schedule 12.08.2008

arrow_upward
1
arrow_downward

Оказывается, в моем случае было очень простое решение. Проект вендора собирает несколько заголовочных файлов в один монолитный заголовочный файл, который затем #included исходниками вендора. Но правило make, создающее монолитный заголовок, случайно включило сгенерированный файл config.h. Наличие переменных конфигурации PACKAGE, VERSION и т. д. в монолитном заголовке вызывало предупреждения о переопределении. Оказывается, config.h поставщика не имело значения, потому что "config.h" всегда разрешался в $(top_builddir)/config.h.

Я считаю, что это то, как это должно работать. По умолчанию подпроект должен включать config.h включающего проекта вместо своего собственного, если только подпроект явно не включает свой собственный или не манипулирует путем INCLUDE, чтобы его собственный каталог находился перед $(top_builddir), или иным образом не манипулирует файлами заголовков, как в моем случае.

person Jason Day    schedule 14.08.2008