Для чего нужен make install и как допиливать dev пакеты?
Вопрос о программировании.
У меня есть либа. Например libFoo. Я делаю ей make install с префиксом в хоум дир. После чего она собирается в два пакета: libFoo и libFoo-dev, ну и получившиеся пакеты инсталим от рута как обычно.
Затем на основе этой либы я пишу свою софтину. Собсно инклубы и либы уже лежат в /usr/local/lib /usr/local/include, соответственно CMake-овский pkg-config либу корректно цепляет, и всё ок.
Пишу значит свою софтину, в хоум-дире, make install я ей не делаю - просто build и run. Добавил ей в CMake find_package(libFoo), слинковал, и всё ок.
Вроде норм всё, не?
А теперь, внимание, вопрос:
в этой libFoo очень много чего недоделано-недопилено. И когда я отлаживаю свою софтину и трассировщиком ухожу в libFoo - я вижу что нужно допилить в этой либе то и сё.
Чтобы редактировать libFoo, на данный момент приходится использовать два IDE/текстовых редактора. libFoo поправил, затем make install-ом прогнал, в пакеты собрал, от рута проинсталил; затем пересобираем свою софтинку, смотрим..
Работает так всё конечно. Но это кошмар как не удобно!
Что хочется: иметь libFoo в виде подпроекта, т.е. добавить её как subdirrectory в CMake-листс моего проекта. Как мне в таком случае с ней работать?
Замечу так же, что make install у неё не тривиальный, т.е. не просто копирует файлы из одного каталога в другой, а имеет некоторую логику..
Вот.
ЕСЛИ ТЫ НИЧЕГО НЕ ПОНЯЛ
Тогда ответь на вопрос концептуальный:
Ведь для сборки пакета я один хрен пишу скрипт, который из каталога с софтиной утягивает только нужные файлики к себе в пакет...
так для чего тогда нужен make install?
- Для комментирования войдите или зарегистрируйтесь
Если ты не ошибся
Если ты не ошибся окошком, то тебе сюда или сюда... :)
Ты не внимательно читаешь
Ты не внимательно читаешь топик старт.ъ
Я же написал: делаю make install в ХОУМ ДИР!!!!!!!!!!!!!!!!!!
Т.е. НЕ ИЗ ПОД РУТА!
Какими блин заглавными буквами писать чтобы ты это увидел?
make install происходит в каталог /home/SysA/libFoo-dev. Затем из этого каталога делается ebuild скриптиком..
Вопрос в том - как работать сразу над несколькими проектами, каждый из который в дальнейшем будет жить в отдельном ebuild-е?
Пока что я вижу только один вариант: написать два совершенно разных CMakelists для каждой из библиотек. Один будет искать нужные либы и инклуды в неком PROJECT_HOME_DIR, заданном через как переменная среда окружения, через export, а другой CMakelists будет рассчитан на то, что либа установлена от рута и будет искать её средствами pkg-config..
/
s/от рута/на системном уровне/
:wq
--
Live free or die
>>Вопрос в том - как работать
>>Вопрос в том - как работать сразу над несколькими проектами, каждый из который в дальнейшем будет жить в отдельном ebuild-е?
Да как душе угодно. Этож творчество. Количество путей неисчислимы. Перед компиляцией, как правило, сборку настраивают. Можно держать два конфига - рабочий и продакшн. Можно делать отдельную цель сборки . Еще один вариант - использование прсевдонадпроекта , который запускает в подпроектах сборки нужной цели с преносом его в нужное место. Вообще выделение продакшн и рабочей сборки это правило, ибо отладочные теги в продакшн коде не нужны.
Ебилд же никакого отношения к процессу разработки не имеет, ибо является необязательной частью проекта как и (опционально) сборка деб или рпм пакетов. К томуже, насколько помню,хорошо воспитанный ебилд не устанавливает файлы при помощи make install.
SysA расскажи лучше: для чего
SysA
расскажи лучше:
для чего нужен make install вообще и в принципе?
Ну и да, для pkg-config-а
Ну и да, для pkg-config-а можно оформить *.pc файлики, чтобы cmake находил либу даже если она не в корень установлена, а куда нибудь в /home/SysA/qweasd/. Так я тоже делал. Но как же подпроект B будет искать либы и инклудники подпроекта A, если тот ещё не собран и не проинстален? Т.е. сделать check на наличие установленного проекта A из CMakelists-а проекта B не представляется возможным..
--------------------------------------------------------
А теперь осталось понять, что я вообще хочу.
Есть проекты, A, B, C. Проекты B и C зависят от A, т.е. тянут от A инклудники и либы.
На данный момент каждый проект устанавливается по отдельности, по очереди. И работать приходиться над каждым проектом по отдельности.
Я же хочу обьединить эти проекты в один проект, и увидеть A B C в виде подпроектов. Чтобы командой make && make install я мог собрать и проинсталлить все три проекта разом. При этом прежняя функциональность - возможность работать и инсталить каждый проект по отдельности - должна сохраниться.
--------------------------------------------------------
Хоть кто нибудь что нибудь понял?
Я понимаю что это вопрос к
Я понимаю что это вопрос к програмиздам, по поводу создания окружения для разработки.
Здорово! Приятно тебя видеть!
Здорово! Приятно тебя видеть! как то стречались на самме камп
Да вопрос к программистам
но и концептуальный впринципе
/
На частном уровне ты можешь копошиться долго и с околонулевым результатом.
Потому рекомендую начать с назначения системы сборки (требованиям к ней и причинам существования зоопарка).
Ибо упоминаемый цмейк — далеко не первый уровень. О характеристике ноги скромно умолчу.
:wq
--
Live free or die
абсолютно верно! поэтому я и
абсолютно верно!
поэтому я и говорю: первоочередной вопрос таков:
зачем нужен make install? как исторически он появился и для чего?
где можно почитать о системах сборки?
/
Ты зачем упорствуешь в ответе на второй вопрос? ☺
Начинать надо с поиска ответа на вопрос: что такое (и зачем оно нужно)
make?install— не более чем одна из стандартных и широкоупотребимых целейmake.Во времена далёкие, теперь почти былинные (помним про ересь) достаточно широко использовалась для копирования устанавливаемых файлов пакета в дерево файловой системы. Сейчас по крайней мере в Gentoo используется для копирования их же в каталог образа (пакета?).
ЗЫ: Если бы у меня был годный ответ на вопрос: где и что почитать, я бы тебя послал туда сразу.
evadimЪ, Вика когда будет?
:wq
--
Live free or die
Anarchist, я прихожу к
Anarchist,
я прихожу к выводу, что make install нужен для формирования среды _запуска_ приложения. Т.е. для копирования всяких конфигов, картинок, данных в те каталоги, от куда приложение будет их читать в "установленном виде".
Это означает что приложение должно собираться (компилироваться и линковаться) без использования make install
Т е когда у нас есть в проекте
libA
libB
binMyGame
то этот проект
1. включает в себя подроект libA liB вот таким вот образом:
2. проект по команде make собирается и линкуется наш бинарник binMyGame
Так должно быть и никак иначе, верно?
Но возникает вопрос с модульностью библиотеки
Например у нас есть
libA/modules/ma/inlcude
libA/modules/mb/inlcude
libA/modules/mc/inlcude
Благодаря флагу -D переданному в аргументы cmake-у, мы включаем только нужные модули. При этом все модули одновременно собраны быть не могут - конфликтуют. Ну например:
libA/modules/video-support-qnx/inlcude/video.h
libA/modules/video-support-freebsd/inlcude/video.h
libA/modules/video-support-gentoo/inlcude/video.h
На данный момент у меня есть подобная библиотека. Она имеет логику (толстый и жирный cmake) на инсталл-таргет. Т е когда мы делаем этой либе make install - она в соответствии с -D ранее переданному cmake-у в качестве аргумента самостоятельно соображает, какой из заголовочных файлов video.h копировать в результирующий каталог CMAKE_INSTALL_PREFIX/include
И я хочу включить такую вот библиотеку в состав своего проекта binMyGame
И получается, что пока мы не сделали make install этой либе, наш binMyGame не знает, какой из video.h ему инклудить
Задним местом чувствую, что где-то что-то криво и как-то всё неправильно..
Согласись, что любой проект со своими зависимостями (подпроектами) должен собираться из ОДНОГО CMakelists-файла - верно?
на данный момент приходиться около десятка раз делать так:
cd ~/libA
mkdir build
cd build
cmake ../
make install
cd ~/libB
mkdir build
cd build
cmake ../
make install
и так 10 раз(!)
Это пипец как неудобно, с учётом того, что каждую из этих либ ещё нужно и допиливать, и трассировать.. ведь они вызывают функции друг из друга..
пониешь мою боль? )
хочется сделать так:
cd ~/rootProject
mkdir build
cd build
cmake ../
make install
и всё - все либы собираются сами и всё линкуется.
законно моё желание по стандартам unix? мне кажется, что если что-то можно сделать из скрипта (я про сборку) - то это должно быть можно сделать и из cmake-а.
Тебе цмаке впрямо впилось и
Тебе цмаке впрямо впилось и жить не дает?
Чистый мейк умеет все,что ты хош,причем сразу и из коробки,написать нужно всего 5 строчек.
В автотулзах нужно будет написать 4 ре строчки, и твоя либа будет пересобитатся,если изменены ее файлы,а если нет - то только твоя прога.
Может быть ты все таки осилишь man make?Если нет,то мои расценки на чтение манов широко известны.
П.С Все твои типа концептуалные вопросы решены лет этак 30-40 назад,вот только хипстеры про это не знают ;)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): Тебе
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
о господи, сколько
о господи, сколько снобизма
ну живи на автомейке и пользуй мониторы 4:3
хотя, спасибо активность конечно
/
Можете развёрнуто и обоснованно изложить требования к монитору? Чем Вам не нравится классика (4×3)?
Вообще с таким отношением к «снобизму» тебя было бы правильно отправить учить матчасть…
Начиная если не с основ, то с первых опытов обобщения.
Фокса ты конечно же знаешь?
:wq
--
Live free or die
почти уверен что видел но уже
почти уверен что видел но уже не вспомню
я тут в отрыв уходил.. на несколько лет.. >_<
/
Русскому переводу (!) источника тридцатник точно есть.
См. анонс классики.
:wq
--
Live free or die
это уже ближе к теме,
это уже ближе к теме, спасибо!
я впрочем уже отписался о решении выше: на такие тяжёлые и запущенные случае и CMake-а есть ExternalProject_Add
идеальный и профессиональный
идеальный и профессиональный ответ, который бы я хотел от тебя получить, может выглядеть как то так:
Флаф, в CMake на такие случаи есть команда ExternalProject_Add и вот на гитхабе пример её использования:
https://github.com/mfreiholz/cmake-example-external-project
slepnoga увы cmake
slepnoga
увы cmake нужен
разработка ведёться из под VisualStudio в том числе..
/
Спросить с фанатов за совместимость с
make.:wq
--
Live free or die
Да я уже придумал решение if
Да я уже придумал решение
if (NOT TARGET ${libName})
pkg_check_modules(${libLabel} ${libName})
endif()
собсно и всё
как извесно, pkg генерит нам полезные имена типа
${libLabel}_INCLUDE_DIRS
${libLabel}_LIB_DIRS
${libLabel}_LDFLAGS
и прочее
Итого мы имеем два варианта
первый, приложение собирается так же как собиралось раньше
# ~/libB/CMakeLists.txt
if (NOT TARGET libA)
pkg_check_modules(LIBA libA})
endif()
messate(STATUS LIBA_INCLUDE_DIRS)
если запустить этот cmake он выведет пути до инклудников
теперь воторой вариант - если мы ту либу используем как подпроект дургого проекта
# ~/CMakeLists.txt
add_subdirectory(libA)
add_subdirectory(libB)
а вот libA теперь должен уметь не только инсталлиться, но и самостоятельно заполнять переменную LIBA_INCLUDE_DIRS:
# ~/libA/CMakeLists.txt
logic_get_include_dirs()
set(LIBA_INCLUDE_DIRS ${INSTALL_INCLUDE_DIRS})
Т е положит он сюда не один каталог, а список каталогов инклудников от нужных модулей
Вроде бы неплохо
Но всё равно смущает костылеобразность сего вроде бы элементарного желания - хотеть обьединить несколько cmake-ов подпроектами в один корневой)
Проблемы дроздофилов свинью
увы cmake нуженразработка ведёться из под VisualStudio в том числе..
Проблемы дроздофилов свинью не волнуют :)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
лечи свою самооценкуя сейчас
лечи свою самооценку
я себя дроздофилом не считаю
да и тебя я видел на самме кампе
тебя свиньёй я тоже не считаю
а к таске ещё добавлю (может потом на статью насобиру)
я придумал ещё более правильный в моём случае способ
если я делаю главный проект, а либы становятся подроетом - то теперь их сборка - это проблема корневого CMakelists.txt
~/project/CMakelists.txt
~/project/libA/CMakelists.txt
~/project/libB/CMakelists.txt
~/project/myGame/CMakelists.txt
как оказалось, если в корневом cmake выполнить команду include_directories - то её значение распространяется и на все последующие проекты, добавленные через add_subdirectory
поэтому я просто вытянул пути с инклудами из моей горе-библиотеки:
add_subdirectory(libA)
get_directory_property(tmp_list
DIRECTORY libA
DEFINITION module_include_dir_list)
foreach(dir ${tmp_list})
list(APPEND LIBA_INCLUDE_DIRS ${CMAKE_SOURCE_DIR}/libA/modules/${dir})
endforeach()
include_directories(${LIBA_INCLUDE_DIRS})
и теперь если далее добавить какой нибудь проект
add_subdirectory(myGame)то он уже и так будет видеть инклудники библиотеки libA и её модулей
ну а далее дело техники
единственное изменение, которое мне придётся сделать в cmake бинарников теперь - это заменить строчку
pkg_check_modules(LIBA libA REQUIRED)
на
pkg_check_modules(LIBA libA)и всё
одно маленькое изменение + новый CMakelists.txt в корне проекта
люблю unix-way за то, что кофеварка варит кофе, а тостер - делает тосты.
f1ufx написал(а): как то
Я там был всего один раз, удивлен тем что меня там кто-то запомнил...
ты мясо привозил, а я тебя на
ты мясо привозил, а я тебя на машине до питера вёз ))
Тогда и я тебя помню (научил
Тогда и я тебя помню (научил маневрам гденипопадя).
В лицо помню, а вот с никами и именами у меня неочень :(
Я кстати сейчас в Питере живу :D
в результате проблему решил
в результате проблему решил так:
указываем флаг CMake-у:
-DCMAKE_INSTALL_PREFIX=/home/flaf/mygame/install
задаём переменную окружения:
PKG_CONFIG_PATH=/home/flaf/mygame/install
после подключения каждого из пакетов, копируем туда *.pc-файл
add_subdirectory(libFoo) # тут генерируется файл *.pc вот этой командой https://cmake.org/cmake/help/v3.0/command/configure_file.html
file(COPY ${CMAKE_CURRENT_BINARY_DIR/libFoo.pc
DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/pkgconfig/libFoo.pc)
add_subdirectory(libBoo)
file(COPY ${CMAKE_CURRENT_BINARY_DIR/libBoo.pc
DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/pkgconfig/libBoo.pc)
Теперь даже слово REQUIRED удалять из pkg_check_module не нужно.