Вопросы | c

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

Вопрос

Jason Day | 1483 просмотров | рейтинг: 5

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



Ответы

Jason Day

+ 3 -
Это определенно хак, но я постобработаю файл config.h autogen'd:
 sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h
 

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


David Joyner

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


Thomas Vander Stichele

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


Теги

c | linux | unix | autoconf | automake