Для чего нужен 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..

/

f1ufx написал(а):
другой 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 я мог собрать и проинсталлить все три проекта разом. При этом прежняя функциональность - возможность работать и инсталить каждый проект по отдельности - должна сохраниться.

--------------------------------------------------------

Хоть кто нибудь что нибудь понял?

Я понимаю что это вопрос к

Я понимаю что это вопрос к програмиздам, по поводу создания окружения для разработки.

Здорово! Приятно тебя видеть!

Здорово! Приятно тебя видеть! как то стречались на самме камп
Да вопрос к программистам
но и концептуальный впринципе

/

f1ufx написал(а):
Да вопрос к программистам
но и концептуальный впринципе

На частном уровне ты можешь копошиться долго и с околонулевым результатом.

Потому рекомендую начать с назначения системы сборки (требованиям к ней и причинам существования зоопарка).

Ибо упоминаемый цмейк — далеко не первый уровень. О характеристике ноги скромно умолчу.

:wq
--
Live free or die

абсолютно верно! поэтому я и

абсолютно верно!
поэтому я и говорю: первоочередной вопрос таков:
зачем нужен make install? как исторически он появился и для чего?
где можно почитать о системах сборки?

/

f1ufx написал(а):
зачем нужен make install? как исторически он появился и для чего?
где можно почитать о системах сборки?

Ты зачем упорствуешь в ответе на второй вопрос? ☺

Начинать надо с поиска ответа на вопрос: что такое (и зачем оно нужно) make?

$ man 1p make

install — не более чем одна из стандартных и широкоупотребимых целей make.
Во времена далёкие, теперь почти былинные (помним про ересь) достаточно широко использовалась для копирования устанавливаемых файлов пакета в дерево файловой системы. Сейчас по крайней мере в Gentoo используется для копирования их же в каталог образа (пакета?).

ЗЫ: Если бы у меня был годный ответ на вопрос: где и что почитать, я бы тебя послал туда сразу.
evadimЪ, Вика когда будет?

:wq
--
Live free or die

Anarchist, я прихожу к

Anarchist,
я прихожу к выводу, что make install нужен для формирования среды _запуска_ приложения. Т.е. для копирования всяких конфигов, картинок, данных в те каталоги, от куда приложение будет их читать в "установленном виде".
Это означает что приложение должно собираться (компилироваться и линковаться) без использования make install
Т е когда у нас есть в проекте
libA
libB
binMyGame
то этот проект
1. включает в себя подроект libA liB вот таким вот образом:

add_subdirectory(libA)

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 назад,вот только хипстеры про это не знают ;)

slepnoga написал(а): Тебе

slepnoga написал(а):
Тебе цмаке впрямо впилось и жить не дает?
Чистый мейк умеет все,что ты хош,причем сразу и из коробки,написать нужно всего 5 строчек.
В автотулзах нужно будет написать 4 ре строчки, и твоя либа будет пересобитатся,если изменены ее файлы,а если нет - то только твоя прога.
Может быть ты все таки осилишь man make?Если нет,то мои расценки на чтение манов широко известны.

П.С Все твои типа концептуалные вопросы решены лет этак 30-40 назад,вот только хипстеры про это не знают ;)
П.П.С на автомейке это вообще поправить 2 пути в стандартном шаблоне :-D,а осиливать цмаке с его undefined behavior конфигом у мну желания нет даже за деньги.

о господи, сколько

о господи, сколько снобизма
ну живи на автомейке и пользуй мониторы 4:3

хотя, спасибо активность конечно

/

f1ufx написал(а):
ну живи на автомейке и пользуй мониторы 4:3

Можете развёрнуто и обоснованно изложить требования к монитору? Чем Вам не нравится классика (4×3)?

Вообще с таким отношением к «снобизму» тебя было бы правильно отправить учить матчасть…
Начиная если не с основ, то с первых опытов обобщения.
Фокса ты конечно же знаешь?

:wq
--
Live free or die

почти уверен что видел но уже

почти уверен что видел но уже не вспомню
я тут в отрыв уходил.. на несколько лет.. >_<

/

f1ufx написал(а):
почти уверен что видел но уже не вспомню
я тут в отрыв уходил.. на несколько лет.. >_<

Русскому переводу (!) источника тридцатник точно есть.
См. анонс классики.

:wq
--
Live free or die

это уже ближе к теме,

это уже ближе к теме, спасибо!
я впрочем уже отписался о решении выше: на такие тяжёлые и запущенные случае и CMake-а есть ExternalProject_Add

идеальный и профессиональный

идеальный и профессиональный ответ, который бы я хотел от тебя получить, может выглядеть как то так:

Флаф, в CMake на такие случаи есть команда ExternalProject_Add и вот на гитхабе пример её использования:
https://github.com/mfreiholz/cmake-example-external-project

slepnoga увы cmake

slepnoga
увы cmake нужен
разработка ведёться из под VisualStudio в том числе..

/

f1ufx написал(а):
увы 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 в том числе..

Проблемы дроздофилов свинью не волнуют :)

лечи свою самооценкуя сейчас

лечи свою самооценку
я себя дроздофилом не считаю
да и тебя я видел на самме кампе
тебя свиньёй я тоже не считаю

а к таске ещё добавлю (может потом на статью насобиру)

я придумал ещё более правильный в моём случае способ
если я делаю главный проект, а либы становятся подроетом - то теперь их сборка - это проблема корневого 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 написал(а): как то

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 не нужно.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".