#c #linux
#c #linux
Вопрос:
У меня вопрос: Многие репозитории не включают библиотеки, в которых есть символы отладки. Итак, это означает, что я должен устанавливать их сам, и обычно они устанавливаются в другие каталоги, чем библиотеки, которые я получаю из своего дистрибутива. Очевидно (?) Я хочу запустить свое реальное приложение с урезанными оптимизированными библиотеками, однако теперь мои make-файлы написаны так, чтобы они работали с пользовательскими скомпилированными библиотеками (которые включают символы dbg) … пример:
-I/ usr/local/include / whatever сейчас является правильным путем, но при развертывании, я думаю, мне понадобится -I / usr /include /whatever
Это всего лишь простой пример, но он показывает, насколько все отличается на моей машине разработки и на моей машине развертывания. Наверняка должно быть какое-то решение, которое люди придумали для борьбы с этим? Вы можете помочь? (кроме очевидных вещей, таких как запись if в make-файл, это некрасиво и недопустимо)
Я просто не понимаю, как кто-то может так работать. Единственное решение — всегда компилировать все самому ..?
Ответ №1:
Отладочная или релизная сборка обычно определяется не в Make-файле, а скорее скриптом configure. То есть у вас есть одно дерево исходных текстов и две сборки из него, одна из которых создает отладочную сборку с использованием флагов отладки (-O0, -ggdb) ваших библиотек (через -I, -L, возможно, задавая rpath), а другая сборка является производственной сборкой с использованием производственных флагов и обычной среды.
Типичная настройка будет выглядеть следующим образом:
svn co my_source_url source
mkdir debug production
( cd debug amp;amp; ../source/configure DEBUG_OPTIONS; )
( cd production amp;amp; ../source/configure PRODUCTION_OPTIONS; )
Комментарии:
1. спасибо, теперь эти скрипты настройки имеют смысл. Однако мне действительно не нравится писать bash-скрипты, это слишком ошибка. Думаю, теперь я знаю, почему люди используют cmake, scons и все такое :). Никогда не видел в этом особого смысла, кроме как сделать Make-файлы менее отстойными
2. @Blub: Не пишите скрипты настройки вручную, позвольте autoconf выполнить эту работу за вас. И он выполняет очень переносимую работу, cmake и scons не могут этого сделать. Вы можете использовать autoconf без automake.
3. титон, спасибо за это предложение. Теперь у меня проблема. Система GNU Buildsystem кажется хорошим выбором, если вы используете make. Однако я не уверен, как это будет сочетаться с моей текущей системой сборки, которую я научился любить (которая не Make, но gittup.org/tup ). Похоже, что GNU Buildsystem требует использования Make в моем наборе инструментов.
4. @Blub: автоконференция зависит только от двух предположений: что реализация «make» не использует символы @ в своем синтаксисе (tup этого не делает) и что она понимает замены переменных «$ {FOO}» (понятия не имею, как tup это делает).
5. титон, tup имеет такой синтаксис: $(CC)
Ответ №2:
Если ваши клиенты выполняют компиляцию.. вам нужен pkg-config
Если ваши клиенты только выполняют .. У вас есть скрипт оболочки запуска, который правильно устанавливает LD_LIBRARY_PATH и выполняет двоичный файл.
Комментарии:
1. rpath — не единственное, что меняется от разработки к развертыванию, поэтому простой лаунчер не принесет никакой пользы. (смотрите Мой пример об измененных путях включения). Также LD_LIBRARY_PATH считается дурным тоном.