Спустя больше года с момента прошлого релиза вышел (http://lists.gnu.org/archive/html/autotools-announce/2009-11...) пакет GNU Autoconf 2.65 (http://www.gnu.org/software/autoconf/), содержащий набор M4-макросов для создания скриптов автоконфугурации для сборки приложений. Начиная с данного выпуска все содержимое пакета Autoconf распространяются только под лицензией GPLv3, дополненной пунктом, разрешающим поставку результирующего конечного "configure" скрипта сборки под лицензией аналогичной приложению в составе которого поставляется данный скрипт.Из улучшений в GNU Autoconf 2.65 можно отметить:
- Добавлены макросы (AC_PROG_OBJCXX, AC_PROG_OBJCXXCPP) для поддержки Objective C++;- Макрос AC_LANG_COMPILER теперь работает на встраиваемых платформах (AVR и RTEMS) в системной библиотеке которых отсутствует вызов fopen;
- Исправлены ошибки в макросах AC_FC_FREEFORM, AC_TYPE_UINT64_T, AC_TYPE_INT64_T, AC_FUNC_MMAP;
- Добавлен новый autotest макрос AT_CH...
URL: http://lists.gnu.org/archive/html/autotools-announce/2009-11...
Новость: https://www.opennet.ru/opennews/art.shtml?num=24367
из знающих, скажите -- чем это лучше чем напрямую напсать сценарий в Makefile ?(думаю стоит начать учить или нет)
>из знающих, скажите -- чем это лучше чем напрямую напсать сценарий в
>Makefile ?
>
>(думаю стоит начать учить или нет)IMHO, лучше учить CMake.
>IMHO, лучше учить CMake.Плюсы CMake сводятся на нет размером и монстрообразностью. Для сборки проекта с autoconf в комплекте уже есть один скрипт configure в сотню килобайт, а для CMake нужно тянуть и ставить пакет в 20 Мб. IMHO, Cmake оправдан только для больших проектов, типа KDE.
> Плюсы CMake сводятся на нет размером и монстрообразностьюВы вообще понимаете о чем говорите? Нельзя придумать ничего глупее, как сравнивать Возможности cmake и какой-то там размер. Тем более что cmake очень легок, а монструозность - удел autocrap'а.
> для CMake нужно тянуть и ставить пакет в 20 Мб
cmake занимает 14MB, 5MB в пакете. Это в разы меньше того же gcc или python, если уж вы упомянули scons.
> Для сборки проекта с autoconf в комплекте уже есть один скрипт configure в сотню килобай
А вот это ложь.
- configure{,.ac,.in}
- Makefile.{in,am}
- {aclocal,acinclude}.m4, m4 (что кому нужно)
- Это все в КАЖДОМ пакете.
- Сами autoconf/automake, если надо собрать что-то из SVN или подправить что-то нетривиальное.Например, из всех пакетов, что установлены у меня на десктопе, autocrap'овский мусор занимает не меньше 428MB.
Хренотень-с говорить изволите-с....# pkg_info -s -x auto
Information for autoconf-2.62:
Package Size:
2559 (1K-blocks)Information for automake-1.9.6:
Package Size:
1489 (1K-blocks)
Разуйте глаза и перечитайте мой пост и что я считал.
>Разуйте глаза и перечитайте мой пост и что я считал.А, ну да... Фокус не навел :)
# du -sh subversion-1.6.6/
49M subversion-1.6.6/# du -sch subversion-1.6.6/configure* $(find subversion-1.6.6/ -name 'Makefile.[ai][nm]')
1,0M subversion-1.6.6/configure
35K subversion-1.6.6/configure.ac
31K subversion-1.6.6/Makefile.in
2,5K subversion-1.6.6/contrib/server-side/svnstsw/include/Makefile.am
...
1,1M total# echo 1.1/49*100 | bc -l
2.24489795918367346900Действительно, 2% - это серъезно.
Забыл добавить, что если вы хоть немного пишите на Python, то идеальный вариант - http://www.scons.org/
>Забыл добавить, что если вы хоть немного пишите на Python, то идеальный
>вариант - http://www.scons.org/SCons мало что решает. Он не такой страшный выродок как autotools, но в смысле кастомизации, например, он еще хуже, потому что по умолчанию нет возможности даже указать CC/CXX/CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS/PREFIX/..., он очищает окружение (так что ccache, например, пролетает). В смысле кросс-платформенности он вообще ноль, потому что для простейших вещей приходится писать кучу if'ов (особенно для зависимостей), и SCons{truct,cript} превращаются в помойку сравнимую с configure.
SCons годится разве что для использования внутри отдельно взятой конторы, где все условия заранее известны и важна повторимость билдов.
plenv = Environment(CPPPATH = ["."])
plenv["CCFLAGS"] = "-DTEST_LEX"Не врите. На сегодняшний день Scons превосходит ВСЕХ на голову.
Лично я же заинтересовался A-A-P (Брама Мулинаара).
> plenv["CCFLAGS"]Снаружи, друг мой, снаружи. Через окружение или коммандную строку. Без правки SCons-файлов.
> На сегодняшний день Scons превосходит ВСЕХ на голову
Попробуйте доказать. Зависимости оно само ищет? Умеет генерить проекты для нескольких DE? Что-то хотя бы отдаленно похожее не ctest и cpack есть? Просто сравните сконструкты и симэйклисты от десятка проектов и посмотрите что короче и читабельней, а что состоит из кучи if sys.platform = .... Потом возьмите эти проекты и попробуйте без модификации собрать, например, на макоси и FreeBSD. Пока вы этим занимаетесь, банальные цифры по коллекции портов FreeBSD:
Портов, использующих cmake/scons: 171/38. cmake уже в разы популярнее.
Из них, портов, в которых упоминиются CMakeLists.txt/SCons(truct|cript) соответственно (что означает правки в системе сборки): 100/33. Т.е. 58%/87%, т.е. scons проекты требуют доводки гораздо чаще. А если внимательно посмотреть на патчи и их объем, SCons начинает выглядеть совсем жалко, ибо большинство патчей для CMakeLists - однострочная фигня типа правки директорий.> Лично я же заинтересовался A-A-P
Сочувствую.
* ...снаружи...
думаю, да :) раз он все-таки использует конструкцию
os.environ.get('HOME', '')
Для командной строки можно пользоваться Alias()-ом.* Зависимости
(глава №6 мануала пользователя, явные/неявные и т.д.). А как по-вашему оно работает? Для C/C++/Fortran - автоматически. Кроме того, можно добавить свои правила и т.д.* Проекты для нескольких DE
это что, developer environment?* ctesk, cpack
Я не пользователь CMake, поэтому не знаю что этоЧто касается "в общем". SCons - это Python, а не что-то свое. Соответственно в нем вы можете сделать все. Ну т.е. абсолютно все. Даже изменить поведение этой системы. А про сочувствие, вызванное интересом к A-A-P, мне кажется, вы не правы. Это хорошая система. Логическое развитие make, внутри опять же доступен весь Python, что делает ее максимально мощной. Написал новое правило проще простого. Посмотрите сами, может быть приглянется.
Проект CMake, насколько я знаю, спонсировался (не то грантом, не то как часть какого-то проекта, не помню) и он довольно старый уже, тогда как A-A-P пишет небезызвестным Б. Муленаар, который, в свою очередь, постоянно просит помочь проекту, его развитию. Тут есть, так сказать, историческая разница :) Это и объясняет кол-во проектов, собираемых ими, о статистике чего вы судите по портам FreeBSD.
Кстати, а вы видели какие проекты успешно ими собираются? И их возможности?
Цитирую Scons:
...
Reliable, automatic dependency analysis built-in for C, C++ and Fortran--no more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types.
Built-in support for C, C++, D, Java, Fortran, Yacc, Lex, Qt and SWIG, and building TeX and LaTeX documents.Built-in support for fetching source files from SCCS, RCS, CVS, BitKeeper and Perforce
Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files.
Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs.
Designed from the ground up for cross-platform builds, and known to work on Linux, other POSIX systems (including AIX, *BSD systems, HP/UX, IRIX and Solaris), Windows NT, Mac OS X, and OS/2.
ну и т.д. Используют:
* Aqsis
* Ardour
* Battlefield 1942
* Blender
* Delta3D
* id Software
* Nullsoft Scriptable Install System
* SuperCollider
* VMware
* Csound5
* Google Chrome[2]Хотя лично мне A-A-P кажется в настоящий момент все-таки более простым.
>* ...снаружи...
>думаю, да :) раз он все-таки использует конструкцию
> os.environ.get('HOME', '')
>Для командной строки можно пользоваться Alias()-ом._По умолчанию_. БЕЗ ПРАВКИ сконструкта. Читайте тред.
>(глава №6 мануала пользователя, явные/неявные и т.д.). А как по-вашему оно работает?
>Для C/C++/Fortran - автоматически. Кроме того, можно добавить свои правила и
>т.д._Внешние_ зависимости. Что за привычка писать бред, даже не прочитав на что отвечаете?
>это что, developer environment?
Да, IDE.
>Я не пользователь CMake, поэтому не знаю что это
Значит и не стоит участвовать в обсуждении систем сборки.
>Что касается "в общем". SCons - это Python, а не что-то свое.
>Соответственно в нем вы можете сделать все. Ну т.е. абсолютно все.Я в курсе. "Все" можно сделать также и на shell, и на ассемблере. Только смысл систем сборки ровно в обратном - делать как можно больше за вас.
>который, в свою очередь, постоянно просит помочь проекту, его развитию
Замечательно. Значит у AAP вообще нет будущего, даже смотреть не стоит.
>Тут есть, так сказать, историческая разница
>:) Это и объясняет кол-во проектов, собираемых ими, о статистике чего
>вы судите по портам FreeBSDЯ смотрел статистику по SCons, а не AAP. AAP не используется вообще нигде.
>Кстати, а вы видели какие проекты успешно ими собираются? И их возможности?
Да, я достаточно видел и достаточно использовал сам оба инструмента (scons и cmake). К scons больше не прикоснусь никогда, и предпочту никогда не сталкиваться с ручной сборкой проектов, его использующих.
>Используют:
Я сразу сказал, что более-менее оно подходит только для закрытых поделок, которые не собираются за пределами компании - вот тут их как раз половина. Для остальных достаточно посмотреть на феерический п--ц, который представляют из себя из SConstruct'ы и как их приходится корёжить чтобы собрать софт. А blender замечательно собирается make'ом.
В итоге мы с вами пришли к выводу, что вам не хватает только make -DXXX?
Все остальное, написанное вами, элементарные эмоции, субъективизм, типа "и не прикоснусь более", "не имеет будущего" и т.п.
Видимо вы Провидец... Вам виднее :)
> В итоге мы с вами пришли к выводу, что вам не хватает только make -DXXX?Видимо это вы один пришли. Я уже достаточно написал чем лучше cmake и чем хуже scons, научитесь читать - продолжим разговор.
waf проще; подходит для мелких и крупных проектов (xmms2, midori)
http://code.google.com/p/waf/
>IMHO, лучше учить CMake.Не хочу ничего сказать но зависимости он обычно детектит горбато.
В чем это выражается? По моему опыту это _единственная_ сборочная система, которая собирает софт из коробке на системах, где сторонние пакеты ставятся в отдельное место (/usr/local, /opt) и обычно требуют указания -I -L. cmake находит их влегкую.
> думаю стоит начать учить или нетНе в коем случае, не тратьте время. autocrap - это autocrap.
Если приложение достаточно сложное и/или имеет много внешних зависимостей - CMake, без вариантов.
Если приложение совсем простое, можно обойтись простеньким Makefile. Для портабельности достаточно не использовать GNU Make - специфичные костыли, и оставить возможность переопределить любые переменные. Примерно так:# Обратите внимание на ?= (не =)
CC?= gcc
CXX?= g++# Обратите внимание на += (не =); никаких -O тут не надо - только то, что критично для успешной компиляции, нормальной работы и диагностики ошибок
CFLAGS+= -Wall -std=c99
CXXFLAGS+=-Wall# Если используются внешние библиотеки, то так:
LDFLAGS?= #empty
CPPFLAGS?= #empty
LIBS= -lm -lpng -ljpeg
# разные системы смогут определить, например, CPPFLAGS=-I/usr/local/include и LDFLAGS=-L/usr/local/liba.o: a.c
${CC} ${CPPFLAGS}|${CFLAGS} -c a.c -o a.oa: a.o
${CC} ${LDFLAGS} ${LIBS} a.o -o aТакой Makefile будет работать без правки где угодно. Простое правило: если у вас в Makefile нужны .if/.ifdef/if/ifdef, используйте CMake.
У тебя банально не отслеживаются зависимости по хидерам: ты изменяешь хидер, а твой проект не пересобирается.
>У тебя банально не отслеживаются зависимости по хидерам: ты изменяешь хидер, а
>твой проект не пересобирается.У меня, если вы не заметили, вообще нет хидеров.
Я не шибко знающий (два проекта средней сложности), но имею вот что сказать.Писать с нуля свои Makefile.am и configure.in -- такой ежедневный подвиг совершенно напрасен. Число и, главное, разнообразие ваших пректов малы и заурядны и никак не требуют знания всех нюансов autotools наизусть -- вы же не пишете новый, совершенно не похожий на предыдущий configure.in дважды на день? Потому достаньте какой-нибудь прожект сходных зависимостей и... ны вы поняли. Это ж опенсорц, елы-палы, а стесняется пусть оригинальный автор качеством свего кода, а не вы.
Другими словами, я особенно не рвусь отстаивать весьма замысловатый синтаксис и структуру autotools, но просто замечаю, что им лет пятнадцать уже, и если они существуют до сих пор, то уж наверное не зря.
Вон, аналогичным образом мысля, если решить не приступать к работе с emacs'ом, предварительно не выучивши все его цепочки и трещинки, то вы не приступите к работе с emacs'ом вообще никогда.
А относительно CMake -- надо будет посмотреть, интересно.
> Писать с нуля свои Makefile.am и configure.in -- такой ежедневный подвиг совершенно напрасенВот именно. И вы думаете что ситема, где написание скрипта для сборки простейшего проекта с нуля считается подвигом, достоина существовать?
> но просто замечаю, что им лет пятнадцать уже, и если они существуют до сих пор, то уж наверное не зря
Знали бы вы сколько дерьма существует в этом мире "наверное не зря". То, что свечи существуют очень долго и тоже наверное не просто так, совешенно не аргумент против использования электричества.
> А относительно CMake -- надо будет посмотреть, интересно
Обязательно посмотрите.
>Вот именно. И вы думаете что ситема, где написание скрипта для сборки
>простейшего проекта с нуля считается подвигом, достоина существовать?Можно прошибать все стены своим лбом, как проприетарщики. А зачем? В опенсорс гордая независимость и самодостаточность нафиг не нужны. Коллективный разум - решает.
>Можно прошибать все стены своим лбом, как проприетарщики. А зачем? В опенсорс
>гордая независимость и самодостаточность нафиг не нужны. Коллективный разум - решает.Можно не прошибать стены лбом - использовать удобные инструменты и не использовать неудобные. Но не все, видимо, ищут легких путей.
Я бы не стал с нахрапом утверждать что установка какого-то добавочного пакета + гемор с глюками - проще чем запуск 1 шеллскрипта, проверенного временем. Хотя, конечно, если вам похрену кто и где осилит компилежку вашей программы - вперед на мины :).
> из знающих, скажите -- чем это лучше чем напрямую напсать сценарий в Makefile ?autoconf нужен только для того, чтобы определить какие фичи на платформе доступны. Например, какой версии ncurses стоит, есть ли поддержка SCTP, ACL, MAC, умеет ли компилятор LTO, использовать ли OpenSSL или GnuTLS и так далее.
Если портируемость на другие ОС не важна, то иногда можно ограничиться ifdef'ами на основе вывода компилятора и версии самой ОС.
$ cc -march=native -dM -E - </dev/null
На *BSD системах, например, automake можно заменить на bsdmake, т.к. на этих системах есть пачка готовых сценариев в /usr/share/mk/
autotools стали не нужны после появления cmake. И извините, но костыли из макросов которые генерят скрипт на полметра для проекта из двух строчек были дикостью с момента своего появления. Надеюсь, ни в одном новом проекте я их больше не увижу, да и старые от них откажутся.
>autotools стали не нужны после появления cmake. И извините, но костыли из
>макросов которые генерят скрипт на полметра для проекта из двух строчек
>были дикостью с момента своего появления. Надеюсь, ни в одном новом
>проекте я их больше не увижу, да и старые от них
>откажутся.И теперь, что бы откомпилировать пять строк, я должен тянуть этот лядский монстроидный cmake? Вместо того что бы воспользоваться заранее сгенерированым Makefile? :)
Сгенерированный чем? autotools? Так он работать не будет.
Ради пяти строк я, так и быть, разрешаю вам написать свой Makefile.
>Сгенерированный чем? autotools? Так он работать не будет.
>Ради пяти строк я, так и быть, разрешаю вам написать свой Makefile.От какой добрый :)
Написать пять строк в Makefile.am, десяток в configure.in
потом пройтись automake/autoconf, что бы мне потом только запустить configure - не, это не кошерно.
А вот наплевать на других, пусть тащат монстроидный cmake, собирают, правят его правила под систему, натравливают на проект - это запросто.Это называется human friendly development :)
>Написать пять строк в Makefile.am, десяток в configure.in
>потом пройтись automake/autoconf, что бы мне потом только запустить configure - не,
>это не кошерно.Я уже сказал что плюсов тут никаких нет - места это жрет в десятки раз больше cmake (если у вас в системе не один пакет), правок требудет больше, а правится гораздо сложнее. Еще раз - ради пяти строчек напишите банальный Makefile - пример я привел, не заставляйте людей качать мегабайты нечитаемых скриптов. Это human friendly. Если банального Makefile не хватает - возьмите cmake, и не заставляйте людей качать мегабайты нечитаемых скриптов и править мегабайты нечитаемых скриптов. Это human friendly.
>А вот наплевать на других, пусть тащат монстроидный cmake, собирают, правят его
>правила под систему, натравливают на проект - это запросто.Вы cmake в глаза не видели, да и Linux тоже, похоже.
>>А вот наплевать на других, пусть тащат монстроидный cmake, собирают, правят его
>>правила под систему, натравливают на проект - это запросто.
>
>Вы cmake в глаза не видели, да и Linux тоже, похоже.# ls -lh /usr/distfiles/cmake-2.6.4.tar.gz
-rw-r--r-- 1 root wheel 3,1M 28 апр 2009 /usr/distfiles/cmake-2.6.4.tar.gz# cmake --version
cmake version 2.6-patch 4# find /usr/local/share/cmake/ -type f | wc -l
377# pkg_info -s -x cmake
Information for cmake-2.6.4:
Package Size:
17626 (1K-blocks)# rlog ~/.bashrc | tail -5
revision 1.1
date: 1997/10/16 14:44:50; author: root; state: Exp;
Initial revision
----------------------------Это все с нетбука, с которого этот пост.
Правила cmake приходилось править неоднократно.
Если бы не знал, то и не писал.
>Это human friendly.Да, зато когда придется этот самый cmake компилячить где-нить - это уже совсем не human friendly. Не говоря о том что зависимости и конфигурацию он проверяет крайне своеобразно, глючит через раз и ломается так что иной раз весь мозг свихнешь пока что-то с оным скомпилишь. Видел несколько прог где конфигур и cmake параллельно пользуются. И если конфигур обычно остреливается без проблем (какие-то глюки я видел 1 раз в жизни) то cmake - доезжает до финиша без приключений или с внятным отлупом спасибо если через раз. Итого - на данном этапе развития человечества при прочих равных я предпочту прогу у которой система сборки на основе автотулзов. Гемора с компилежкой как-то меньше.
Ну нужен. Все вменяемые люди давно свалили на cmake. Кое-кто на убожество scons, но потом все равно на cmake.
>Ну нужен. Все вменяемые люди давно свалили на cmake. Кое-кто на убожество
>scons, но потом все равно на cmake.А вменяемый - это вы лично?
>А вменяемый - это вы лично?Ну уж явно не человек, который не может поставить 3MB пакет, которым уже собирается куча софта из-за причин, которые он затрудняется назвать.
>>А вменяемый - это вы лично?
>
>Ну уж явно не человек, который не может поставить 3MB пакет, которым
>уже собирается куча софта из-за причин, которые он затрудняется назвать.# pkg_info -s -x cmake-2.*
Information for cmake-2.6.4:
Package Size:
17626 (1K-blocks)# cd /usr/bsdports
# grep -l 'USE_CMAKE' devel/*/Makefile net*/*/Makefile www/*/Makefile | wc -l
25
# grep -l 'GNU_CONFIGURE' devel/*/Makefile net*/*/Makefile www/*/Makefile | wc -l
1090То есть на какой-нить HPUX мне придется для откомпилировать софтинку тянуть-компилировать еще и cmake?
Ибо у него правила проверки не инкорпорирированы, как в configure, а отдельно?# ls -1 /usr/local/share/cmake/Modules | wc -l
280Учитывая что он на с++, то встретить кучу косяков на ровном месте...
# du -sh cmake-2.6.4/Source/
8,2M cmake-2.6.4/Source/
Или опять - на свете есть только любимый Linux, и нет иного?
>То есть на какой-нить HPUX мне придется для откомпилировать софтинку тянуть-компилировать еще
>и cmake?Представьте себе, также как и autotools, gcc, make и тулчейн.
>Ибо у него правила проверки не инкорпорирированы, как в configure, а отдельно?
>Учитывая что он на с++, то встретить кучу косяков на ровном месте...Далее следует феерический неаргументированный бред, с приведением каких-то размеров и количест файлов.
>Или опять - на свете есть только любимый Linux, и нет иного?
Во-первых, если вы не заметили, у меня не Linux. Во-вторых, ИМЕННО, что есть иное, и на этом ином autotools и scons требуют на порядок больше геморроя, чтобы собрать софт.
>>То есть на какой-нить HPUX мне придется для откомпилировать софтинку тянуть-компилировать еще
>>и cmake?
>Представьте себе, также как и autotools, gcc, make и тулчейн.Фигасе? :)
Для того, что бы настроить (конкретизировать) Makefile пакета c autoconf/automake, необходимо иметь на целевой системе:
gzip, tar, shell, make (иногда - gnu make), родной компилятор#gunzip soft.tar.gz
#tar xf soft.tar
#cd soft
#СС='icc' CPPFLAGS='-I/opt/include' ./configure --prefix=/opt
#make
#make installНеобходимости в наличии на целевой системе autoconf/automake/libtool/m4/perl - нет.
В отличие от cmake.>
>Далее следует феерический неаргументированный бред, с приведением каких-то размеров и количест файлов.Не умеете анализировать - ваши проблемы.
Для вас вывод размера кода с++ (8.7Mb), который предстоит портировать при неизвестном его качестве - феерический бред, то тогда о чем вам писать?>
>>Или опять - на свете есть только любимый Linux, и нет иного?
>
>Во-первых, если вы не заметили, у меня не Linux. Во-вторых, ИМЕННО, чтоГде написано? Как заметить? На основании каких букв? Что это 1005-й анонимус? :)
Или вы великий телепат? Потрудитесь хотя бы зарегистрироваться с вменяемым ником.>есть иное, и на этом ином autotools и scons требуют на
>порядок больше геморроя, чтобы собрать софт.scons - не знаю, но autoconf/automake и cmake - один фик. Только по разному реализована логистика сборки.
cmake - он же и configure, и make, со своим языком правил достижения целей и макропроцессирования.И если сунуться в макроправила cmake - там таже хрень, что и в automake/autoconf.
Четыре сотни макропакетиков cmake, поди в них потыркайся и разберись, что и когда в них сработало, плюс 9mb с++ кода самого cmake.А выход configure - банальный Makefile & config.h, плюс простой для понимания config.log
Просто и сердито. Ну уж понять язык скриптов - это для профессионала, думаю, как книгу читать. И для работы autoconf/automake необходимы m4 и perl, а сейчас надо поискать систему, где их нет.Так преимущества cmake очень иллюзорны.
> Ну уж явно не человек, который не может поставить 3MB пакет,Знаете, не у всех людей есть root на машинах, где они работают.
Бывают, к примеру, конторы, использующие линукс и рута не любят давать.
>Знаете, не у всех людей есть root на машинах, где они работают.И что? cmake можно также поставить из-под юзера.
>И что? cmake можно также поставить из-под юзера.А у автотулсов насколько я помню - как правило вообще ничего не надо ставить на target-е. Просто пинаем конфигур и усе. Как-бы есть некоторая разница между изгалениями по поводу установки чего-то там куда-то там и простым запуском шелл-скрипта.
Тоже хотел спросить, но почитал тред и уже ответили. Учу cmake.