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

Question

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

Answer 1

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

• Вы не упомянули, как 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 в любом месте из ваших публично установленных заголовков.

Answer 2

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

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

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

Answer 3

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

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