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

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

У меня есть проект (я назову его myproject), который включает в себя другой проект (поставщика). Проект вендора - это отдельный проект, поддерживаемый кем-то другим. Включение такого проекта довольно просто , но в этом случае есть небольшая загвоздка: каждый проект генерирует свой собственный config.hфайл, каждый из которых определяет стандартные макросы, такие как PACKAGE, VERSION и т. Д. Это означает, что во время сборки, когда поставщик строится, я получаю много ошибок, как это:

... 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, которая не сильно помогает. У кого-нибудь есть идеи получше?

10.08.2008 23:10:53
3 ОТВЕТА
РЕШЕНИЕ

Некоторые заметки:

  • Вы не упомянули, как это 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нигде из ваших публично установленных заголовков.
5
23.05.2017 12:01:17

Это определенно хак, но я постобработаю config.hфайл autogen'd :

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

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

2
8.10.2015 01:12:02

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

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

1
14.08.2008 16:16:56