система для сборки с зависимостями для C++

php-макаки
а сейчас нужно переходить на C++ с Unreal Engine,

Поверь мне, отсутствие maven для c++ - ваша самая незначительная проблема.

поэтому нужно использовать autotools на баше ?)

как будто что-то плохое

А что же господин понилюб вместо cmake юзает? Automake&Autoconf, которые по своей уродливости конфиг sendmail обогнали?

В чём уродливость Automake&Autoconf?

Да хотя-бы в

When calling macros that take arguments, there must not be any white space between the macro name and the open parenthesis.

Это вообще пушка - лишний пробел не в том месте, и все упало. Да и вообще M4 - древнее и пахучее гуано, которое уже давно закопали, и писать систему сборки, юзающую M4 в 2015 году - ретроградство.

как будто что-то плохое

Если планируется выход за пределы Unix-а, то да :)

украл, спасибо

этот мезон - это твой проект?

там как-таковых постоянных 2 разработчика. Jussi Pakkanen и я

mesonbuild.com предполагается захардкоидть, или в недрах гитхаба можно вытянуть этот сайт и его веб-интерфейс, и поднять локально? Ну, чтобы не нудить в гуглогруппу «добавь фигнюшку, ну добавь фигнюшку» (особенно если это какая-то внутренняя фигнюшка, шарить которую не даст начальство)

а, это походу https://github.com/mesonbuild/wrapweb

https://github.com/mesonbuild/wrapweb/

лучше пиши в #mesonbuild at FreeNode заявки на добавление проектов или в https://github.com/mesonbuild/wrapweb/issues

Вот ещё: https://github.com/mesonbuild/meson/wiki/Adding-new-projects-to-wrapdb

Если планируется выход за пределы Unix-а, то да :)

в cygwin-е всё прекрасно работает

https://www.biicode.com/

плохое. медленный и чтобы на нём хоть что-то нормально сделать - нужно лет 5 им заниматься.

1-2 недели вполне достаточно, чтобы освоить

в cygwin-е всё прекрасно работает

Cygwin придумали специально для упоротых Unix-оидов, которые никак не могут понять, что жизнь есть и за пределами их уютного мирка :)

Если серьезно, cygwin можно было бы рассматривать, если бы эмуляция posix-а не имела таких серьезных накладных расходов.

https://github.com/hughsie/appstream-glib/commit/98665de514994935d49e8f7eb824...

тогда скажи мне, почему человек, который имеет очень много лет опыта с autocrap делает такие ошибки?

ответ прост, потому что в autocrap куча boilerplate-кода, который копируется-перекопируется из одного проекта в другой. никто и никогда в жизни не разберётся как там что работает. фиксится примерно: «давай добавим это, сработало?»

особенно если это какая-то внутренняя фигнюшка, шарить которую не даст начальство

не прочитал сразу. да, без проблем. берёшь сервер, разворачиваешь у себя. у меня там даже rpm пакеты есть. правда, там настроено только для интеграции с github.com/mesonbuild, но patches are welcome. если и правда заинтересовало.

мы все сидим на #mesonbuild at freenode, там быстрее всего потыкать с любыми вопросами.

в autocrap куча boilerplate-кода, который копируется-перекопируется из одного проекта в другой. никто и никогда в жизни не разберётся как там что работает. фиксится примерно: «давай добавим это, сработало?»

Когда (точнее, если) у тебя будет поддерживаться столько же платформ, вспомни эти свои слова.

autocrap уже научился в кросс-платформенность?

в CMake ещё хоть как-то это работает. в meson работает ещё лучше.

а чем конкретнее? а то увидел впервые - штука на мой взгляд архиполезная, какие аргументы против нее?

1. Насколько я понял, она жестко создает иерархию проекта на файловой системе так как ей хочется, а не как тебе удобно.

2. Было бы удобнее, чтобы внешние зависимости выкачивал git, а не отдельный скрипт. В таком случае, при checkout конкретной ревизии у тебя на файловой системе будут согласованные версии и твоих исходников и зависимостей, без запуска отдельного скрипта (т.е. файлы проекта и его зависимостей будут всегда согласованы). В этом плане рулит и педалит svn externals. Было бы клево, если бы в git было нечто подобное. Указал, что хочешь вот в этой папке (external_projects/subproject_1) иметь вот это поддерево конкретной версии внешнего проекта и git его выкачал. Обновил свои файлы исходников, перешел на другую версию внешнего проекта, поправил данные git:externals и оп, в этом коммите у тебя изменяются как твои файлы, так и зависимости. Типа git submodules, только с возможностью в качестве модуля в указанную папку брать не корень репозитория, а конкретную поддиректорию подпроекта. В 99% случаев этой функциональности хватит (если бы git externals работал не только с git), в остальных случаях можно и отдельный скрипт использовать.

autocrap уже научился в кросс-платформенность?

meson уже научился в Solaris 2.5?

в CMake ещё хоть как-то это работает. в meson работает ещё лучше.

Meson рулит, мы поняли.

autocrap уже научился в кросс-платформенность?

meson уже научился в Solaris 2.5

разговор про autocrap. и нет, не умеет.

Meson рулит, мы поняли.

больше рулит ninja, чем meson. automake == meson, makefile == ninja.

autocrap уже научился в кросс-платформенность?

meson уже научился в Solaris 2.5

разговор про autocrap. и нет, не умеет.

Разговор про

i_gnatenko_brain> в CMake ещё хоть как-то это работает. в meson работает ещё лучше.

А про «meson рулит» - это была ирония. Еще одна система для полутора анонимусов.

Еще одна система для полутора анонимусов.

посмотрим после GUADEC.

Немного другие примеры: легко пользоваться apt-get install package, но только два с половиной землекопа умеют делать свои собственные пакеты, а уж выложить их в официальные репозитории убунты - вообще труба.

У меня создается впечатление, что 99.9% разработчиков полные дегенераты...

вроде крутая штука. Если будет время (маловероятно, но вдруг) попробую чонить помочь. Постучусь во фриноду.

(К сожалению, не шарю в питоне, честно признаюсь. Написал на нём полтора скрипта за всю жизнь, там где на баше было противно. Но могу например забацать альтернативную морду на джаве и angularjs или что-то такое :)

Большинство пользователей CMake вообще работают по принципу копи-пасты, не особо разбираясь в самом инструменте.

Кто захочет - разберется.

А многие, полагаю, даже не видят CMakeLists.txt в глаза, т.к. за них все делает IDE.

Ну и откуда такие выводы? Сколько-нибудь нормальная поддержка cmake в IDE появилась, наверное, только в clion, который пару месяцев назад выпустил версию 1.0. Остальные IDE поддерживают cmake очень поверхностно. Это я к тому, что CMakeLists.txt пишут руками.

Если бы кому-нибудь из них довелось в синтаксисе CMake описывать особенность сборки под какой-нибудь уникальной конфигурацией, стона и плача было бы на весь Интернет :)

А если это будет сделано в scons или mxx, то как оно работает сможет разобраться только единственный человек - Писатель.

на джаве и angularjs

изыди =)

# ps -eo rss,command | grep -P "(nginx|meson-wrapweb)"
  816 grep --color=auto -P (nginx|meson-wrapweb)
 4212 nginx: master process /usr/sbin/nginx
 9936 nginx: worker process
 9700 nginx: worker process
 9936 nginx: worker process
 9936 nginx: worker process
24752 /usr/sbin/uwsgi --ini meson-wrapweb.ini
20636 /usr/sbin/uwsgi --ini meson-wrapweb.ini
20412 /usr/sbin/uwsgi --ini meson-wrapweb.ini
20464 /usr/sbin/uwsgi --ini meson-wrapweb.ini
21184 /usr/sbin/uwsgi --ini meson-wrapweb.ini

ну, не могут некоторые осилить кресты, ну что ж теперь? я постоянно вижу на форумах вопросы о «программировании на Qt», причём вопрошающие иногда вообще ничего не знают о С++. они в Qt Creator'е лепят формы и пытаются наугад что-то нагородить в коде. я на собеседованиях при приёме на работу периодически вижу непонимание того, что такое компилятор, линкер и вообще, для некоторых код превращается в бинарник каким-то неведомым магическим образом. и это всё ширится и распространяется. и потом приходится править тонны говнокода. или выкидывать целые модули и переписывать. потому что переписать бывает проще, чем исправить. я не хочу видеть неосиляторов на работе. их не должно быть среди профессионалов. пусть лучше программистов будет меньше в десять раз, но чтобы они были вменяемыми и понимали, что делают.

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

макаки одного вида для решения проблемы сборки выбрали макаку другого вида. it will be a zoo...

Удивительно другое: что популярность получает именно CMake.

Назови более удобную альтернативу... Функционала и скорости работы у него достаточно. Остается удобство использования. Что удобнее - тем и пользуются.

поэтому нужно использовать autotools на баше ?)

Они на перле, а он есть везде.

Кто захочет - разберется.

Ну вот я захотел, полазил по официальному сайту, почитал то, что авторы CMake называют документацией, поспрашивал знакомых и сильно загрустил. Разбираться со SCons-ом, MPC или Jam-ами было проще.

Ну и откуда такие выводы?

Да вот, сложилось такое впечатление от общения с теми, кто ратует за CMake. Копипаста рулит и бибикает.

А если это будет сделано в scons или mxx, то как оно работает сможет разобраться только единственный человек - Писатель.

Если это будет сделано в SCons или mxx, то это будет сделано, по крайней мере, на нормальном языке программирования. А не на том мрачном DSL-е, которые смогли придумать авторы CMake.

Назови более удобную альтернативу... Функционала и скорости работы у него достаточно.

У меня есть альтернатива, функционала и скорости работы достаточно. Но это собственный лисапет, продвигать который в массы нет возможности. К тому же он не является менеджером зависимостей.

Из того, с чем приходилось знакомиться больше всего нравился SCons.

Хотя нужно заметить, что генераторы make-файлов мне вообще не нравятся. Так что инструменты вроде CMake, MPC или GYP проходят мимо :)

Они на перле

не особо важно =)

а он есть везде.

у меня в системе, например, нет. правда и автокрапа тоже нет.

ну, для обучения существуют университеты. а на производстве от работника ожидают, как минимум, знания языка программирования и базовых инструментов для работы. то, что тупней развелось до чёрта, не означает, что нужно принимать на работу кого попало.

нуу, местами и так приходится. да, и хорошо, если баш есть. но CMake обычно собирается под чем угодно, ибо он сишный и особых сложностей с его сборкой не возникает. всё же проще, чем через какие-то специальные тулзы. и легче, чем напрямую через Makеfile'ы.

Я думаю, причина в том, что есть много разных систем и тулчейнов

это никак не мешает, другие как-то собирают кучу зависимостей совершенно разными компиляторами разных языков.

Пока я не вижу явного победителя даже среди систем сборки.

я именно об этом и говорю

Если это в мою сторону, то мимо.

это, внезапно, в сторону C++ программистов.

Он интегрирован в Make.

а Make в операционке от святого духа заводится? его точно так же нужно доустанавливать, у меня, например, его можно найти на меньшем количестве систем, чем джаву.

никакой магии там нет, всё элементарно, дистрибутивы предоставляют полную документацию

буквально недавно пытался найти документацию о том как rpm сравнивает версии. максимум что у меня получилось найти - предложение использовать perl-либу для сравнения. это к вопросу об элементарности и полной документации.

в таком случае, наверное, проще посмотреть в код. опенсорц тем и хорош, что всегда можно посмотреть сорцы и всё понять. или даже что-то переделать под свои нужды.

Я думаю, причина в том, что есть много разных систем и тулчейнов

это никак не мешает, другие как-то собирают кучу зависимостей совершенно разными компиляторами разных языков.

Например? Все языки со стандартными системами сборки, которые я могу припомнить навскидку - это языки с доминирующей реализацией. pip, gem, maven, omake, cargo.

Он интегрирован в Make.

а Make в операционке от святого духа заводится?

Можно считать, что да.

его точно так же нужно доустанавливать

Ты равняешь установку Make с установкой Java? Серьезно?

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

Зависит от того, что понимается под «системой». Впрочем, меня не волнуют проблемы венды и прочих не-Linux.

буквально недавно пытался найти документацию о том как rpm сравнивает версии. максимум что у меня получилось найти - предложение использовать perl-либу для сравнения

«For the exact (non-symmetric) algorithm, see lib/vercmp.c in the RPM source code» (ц)

Например?

Например все тобой перечисленые.

Ты равняешь установку Make с установкой Java?

До тех пор пока не приведен критерий по которому можно определить, что можно ставить, а что нет - да.

Зависит от того, что понимается под «системой». Впрочем, меня не волнуют проблемы венды и прочих не-Linux.

Все исключительно инсталляции линуксов, родной.

«For the exact (non-symmetric) algorithm, see lib/vercmp.c in the RPM source code» (ц)

rpm используется в миллионе дистрибутивов линукса и в не-линуксах тоже. Какой именно исходник какой версии мне нужно взять чтобы работало более - менее везде?

Ты равняешь установку Make с установкой Java? Серьезно?

А в чем разница между «apt-get install openjdk-8-jre» и «apt-get install make». Или всё еще экономите байтики на HDD девелоперской раб. станции?

Я думаю, причина в том, что есть много разных систем и тулчейнов

это никак не мешает, другие как-то собирают кучу зависимостей совершенно разными компиляторами разных языков.

Например? Все языки со стандартными системами сборки, которые я могу припомнить навскидку - это языки с доминирующей реализацией. pip, gem, maven, omake, cargo.

Например все тобой перечисленые.

Хм. Мне кажется, ты не читаешь то, что тебе пишут.

Зависит от того, что понимается под «системой». Впрочем, меня не волнуют проблемы венды и прочих не-Linux.

Все исключительно инсталляции линуксов, родной.

Окей. У меня тоже есть десятки систем без make. Правда, не знаю, какой вывод я должен сделать из этого.

rpm используется в миллионе дистрибутивов линукса и в не-линуксах тоже. Какой именно исходник какой версии мне нужно взять чтобы работало более - менее везде?

Так от множества тулчейнов Ocaml и Rust мы переходим к множеству алгоритмов сравнения номеров версий...

А в чем разница между «apt-get install openjdk-8-jre» и «apt-get install make».

Ты не поверишь, но есть Linux-ы без Java.

Или всё еще экономите байтики на HDD девелоперской раб. станции?

Мы экономим количество софта, участвующего в сборке.

Даёшь libcmake и интеграцию в IDE

На кой? Он и так для всех существующих IDE проекты генерить умеет.

Ты не поверишь, но есть Linux-ы без Java.

Ну каждый упарывается по своему. Мне вот Haiku тоже нравится, но я же не поднимаю её на раб. станции. Раб. станция на то и раб. станция, что на ней можно все быстро поднять и попробовать.

Мы экономим количество софта, участвующего в сборке.

Я предпочитаю экономить время. А сколько у меня там пакетов стоит, мне пофиг, ибо не продакшен и не 10 Гб диск.

Ты не поверишь, но есть Linux-ы без Java.

Ну каждый упарывается по своему. Мне вот Haiku тоже нравится

Что за детство - «упарывается», «нравится»? Есть целевая платформа и программа должна собираться на ней.

Мы экономим количество софта, участвующего в сборке.

Я предпочитаю экономить время.

Ты не поверишь, но в моем случае минимальное количество софта, участвующее в сборке - это именно сэкономленное время. Человеческое время, не машинное.

есть Linux-ы без Java

Кажется ты не читаешь что тебе пишут.

Мы экономим количество софта, участвующего в сборке.

Так перестань использовать разные варианты make, используй везде maven, останется только один используемый софт

есть Linux-ы без Java

используй везде maven

okay.jpg