История изменений

А нельзя вытащить из gcc или из make какой-нибудь лог, чтобы увидеть все хедеры, с которыми он по умолчанию компилирует тот или иной объектник?

Поделюсь тем, как я вижу ситуацию. Я так понимаю, исходные данные: некий проект, для которого есть исходники, и которых хочется собрать и опакетить. Во-первых, нужно разделять сборку проекта и «опакечивание». Второе является специфичной для дистрибутива задачей, а первое - для проекта.

Я обычно делаю так. Нужно собрать проект при штатном окружении дистрибутива, имеется ввиду без установки зависимостей костылями вида make install, а только пакетным менеджером. Предполагаю, что собирается наиболее часто используемым способом. Поэтому итеративно запускаю ./configure && make, и выписываю все ошибки которые относятся к зависимостям - ненайденные хедеры, unreferenced link. Ищу по именам функций, хедеров и другим особенностям гуглом и yum provides <что>(поддерживает маски wild card), если не знаю, к какому пакету в данном дистрибутиве относится зависимость. Ставлю нужный, yum install <needs>-devel. В случае отсутствия пакета в дистре - гуглю усЕрднее, и, если ничего выяснить не удается, то приходится зависимость тоже опакечивать. Ну вот, в итоге у меня полчился список зависимостей для проекта, и они уже установлены, проект собирается. Теперь, даже не указывая BuildRequires в spec файл, ты можешь сделать rpmbuild -ba <proj>.spec и rpm соберется. Далее, как указали выше, понадобится auto-buildrequires в дополнении к составленному списку зависимостей. Пишу список BuildRequires в spec.

Причем, как уже заметили, зависимости автоматически попадают в rpm. Ты можешь убедиться в этом, зайдя в .rpm файл как в архив, например Midnight Commander-ом, и посмотрев файл INFO/REQUIRENAME - там будут указаны зависимости твоего пакета, в том числе те, которые автоматически нашлись. Для регулировки версий зависимостей и неявных - нужно Requires в spec.

И читай еще раз и еще больше мануалов и доков по всем командам, включая ./configure --help проекта. Все нюансы я в посте не охвачу конечно же, да и не знаю

А нельзя вытащить из gcc или из make какой-нибудь лог, чтобы увидеть все хедеры, с которыми он по умолчанию компилирует тот или иной объектник?

Поделюсь тем, как я вижу ситуацию. Я так понимаю, исходные данные: некий проект, для которого есть исходники, и которых хочется собрать и опакетить. Во-первых, нужно разделять сборку проекта и «опакечивание». Второе является специфичной для дистрибутива задачей, а первое - для проекта.

Я обычно делаю так. Нужно собрать проект при штатном окружении дистрибутива, имеется ввиду без установки зависимостей костылями вида make install, а только пакетным менеджером. Предполагаю, что собирается наиболее часто используемым способом. Поэтому итеративно запускаю ./configure && make, и выписываю все ошибки которые относятся к зависимостям - ненайденные хедеры, unreferenced link. Ищу по именам функций, хедеров и другим особенностям гуглом и yum provides <что>(поддерживает маски wild card), если не знаю, к какому пакету в данном дистрибутиве относится зависимость. Ставлю нужный, yum install <needs>-devel. В случае отсутствия пакета в дистре - гуглю усЕрднее, и, если ничего выяснить не удается, то приходится зависимость тоже опакечивать. Ну вот, в итоге у нас полчился список зависимостей для проекта, и они уже установлены, проект собирается. Теперь, даже не указывая BuildRequires в spec файл, ты можешь сделать rpmbuild -ba <proj>.spec и rpm соберется. Далее, как указали выше, понадобится auto-buildrequires в дополнении к составленному списку зависимостей. Пишу список BuildRequires в spec.

Причем, как уже заметили, зависимости автоматически попадают в rpm. Ты можешь убедиться в этом, зайдя в .rpm файл как в архив, например Midnight Commander-ом, и посмотрев файл INFO/REQUIRENAME - там будут указаны зависимости твоего пакета, в том числе те, которые автоматически нашлись. Для регулировки версий зависимостей и неявных - нужно Requires в spec.

И читай еще раз и еще больше мануалов и доков по всем командам, включая ./configure --help проекта. Все нюансы я в посте не охвачу конечно же, да и не знаю

А нельзя вытащить из gcc или из make какой-нибудь лог, чтобы увидеть все хедеры, с которыми он по умолчанию компилирует тот или иной объектник?

Поделюсь тем, как я вижу ситуацию. Я так понимаю, исходные данные: некий проект, для которого есть исходники, и которых хочется собрать и опакетить. Во-первых, нужно разделять сборку проекта и «опакечивание». Второе является специфичной для дистрибутива задачей, а первое - для проекта.

Я обычно делаю так. Нужно собрать проект при штатном окружении дистрибутива, имеется ввиду без установки зависимостей костылями вида make install, а только пакетным менеджером. Предполагаю, что собирается наиболее часто используемым способом. Поэтому итеративно запускаю ./configure && make, и выписываю все ошибки которые относятся к зависимостям - ненайденные хедеры, unreferenced link. Ищу по именам функций, хедеров и другим особенностям гуглом и yum provides <что>(поддерживает маски wild card), если не знаю, к какому пакету в данном дистрибутиве относится зависимость. Ставлю нужный, yum install <needs>-devel. В случае отсутствия пакета в дистре - гуглю усЕрднее, и, если ничего выяснить не удается, то приходится зависимость тоже опакечивать. Ну вот, в итоге у нас полчился список зависимостей для проекта, и они уже установлены, проект собирается. Теперь, даже не указывая BuildRequires в spec файл, ты можешь сделать rpmbuild -ba <proj>.spec и rpm соберется.

Причем, как уже заметили, зависимости автоматически попадают в rpm. Ты можешь убедиться в этом, зайдя в .rpm файл как в архив, например Midnight Commander-ом, и посмотрев файл INFO/REQUIRENAME - там будут указаны зависимости твоего пакета, в том числе те, которые автоматически нашлись. Для регулировки версий зависимостей и неявных - нужно BuildRequires в spec.

И читай еще раз и еще больше мануалов и доков по всем командам, включая ./configure --help проекта. Все нюансы я в посте не охвачу конечно же, да и не знаю