LINUX.ORG.RU

Проект mesa3d перешёл на сборочную систему meson


2

3

autotools убрали, в 19.1 не будет.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=95aefc94a941701616fda0776a3...

Пришлось учить meson. Т.е. копипастить строку настроек, любезно предоставленную одним тестером:

https://lists.freedesktop.org/archives/mesa-dev/2019-April/217409.html

Сначала нужно создать директорию, где будет собираться проект, я создал BUILD в корне исходников mesa и перешёл туда.

Внимание, по-умолчанию если у вас есть ccache он будет использован, у меня чуть место в $HOME не кончилось.

Я скопипастил такое (префикс мой особенный, у остальных куда-то в /usr):

meson ../ --prefix=/usr/X11R7 --strip --buildtype debugoptimized -Degl=true -Ddri-drivers=r100,r200,i965,nouveau -Dplatforms=drm,x11 -Dgallium-drivers=i915,r600,radeonsi,swrast,virgl,nouveau,r300 -Dvulkan-drivers=amd,intel  -Dgallium-nine=true -Dgallium-opencl=icd -Dgallium-va=true -Dgallium-xvmc=true --reconfigure 
ninja

От рута: ninja install

★★★★

Ответ на: комментарий от byko3y

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

Дерево зависимостей модулей в Delphi/fpc, если что, там строится по директиве uses, которая синтаксически элемент языка, а не директива сбоку-припёки-препроцессора. Если uses выстроены правильно, значит, и порядок будет правильный.

Вот про внешние библиотеки не скажу. Не помню.

императивочка здесь - от лукавого

Тут согласен. Избыточность той же cmake в том, что это — скриптовый язык, на котором можно писать В ТОМ ЧИСЛЕ сборочные последовательносте. Вот и получается, что с одной стороны, слишком много буков, а с другой стороны, очень мало чего контролируется при парсинге.

hobbit ★★★★★
()
Ответ на: комментарий от byko3y

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

Разве компилятор/линковщик в Pascal / Delphi такой же тупой, как и ld из GNU Binutils / GCC и ему нужно давать пинок под зад (правильный порядок) иначе он ничего не видит? Мне кажется в Pascal / Delphi там строилось дерево. Но я не уверен.

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

В Gradle, например, используется Groovy. Но там другая проблема – монструозная JVM в довесок.

EXL ★★★★★
()

Посмотрел, кстати, на файлы meson.build из репы сабжа, например, на этот. Ну вроде, выглядит попристойнее, чем cmake. Хотя не покидает мысль, что можно было сделать ещё стройнее...

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Хотя не покидает мысль, что можно было сделать ещё стройнее…

Да, например, избавиться от ублюдочных endif, endforeach и т. д.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Отсутствие стандартов это проблема, да. Но тут едва ли в сторону cmake можно что-то сказать - без учёта autotools, больше всего используется(ИМХО, разумеется). Может стоит поддерживать только его, остальные быстрее вымрут?

Deleted
()
Ответ на: комментарий от EXL

Мне кажется в Pascal / Delphi там строилось дерево.

Всё правильно.

hobbit ★★★★★
()
Ответ на: комментарий от Deleted

Я использую CMake, а не Meson во всех случаях. Альтернативы хоть и выглядят лучше, но многим не устраивают. Но я совсем не хочу, чтобы CMake стал стандартом, особенно после таких радикальных решений от Kitware, ломающих совместимость и всё доверие к проекту:

Мы бандлим модули ко всем библиотекам, ура! Разработчики смогут подключать зависимости одной строчкой, это очень удобно!

(Прошло два года)

Теперь мы не бандлим модули к библиотекам вообще, потому что неосиляторы! Пок-пок-пок. Разбирайтесь теперь в помойке, которая случится после нашего отказа, лол.

Популярность CMake вызвана лишь тем, что на него начали завязываться крупные компании вроде Google и прочих, а альтернатив тогда никаких толком и не было.

Сейчас они появились, всякие разные (от premake до waf) и более адекватные, чем CMake со своим недоDSL, неочевидностями и кашей из модулей. Используют полноценные языки программирования, позволяющие очень тонко настроить сборку и т. д. адекватными языковыми конструкциями, а не поносом вида:

list(LENGTH LOCALES LOCALES_SIZE)
math(EXPR LOCALES_SIZE_MAX "${LOCALES_SIZE} - 1")
foreach(VAL RANGE ${LOCALES_SIZE_MAX})
	list(GET LOCALES ${VAL} LOCALE)
	math(EXPR VAL_PREVIOUS "${VAL} - 1")
	list(GET LOCALES ${VAL_PREVIOUS} LOCALE_PREVIOUS)
	if(${VAL} EQUAL 0)
		set(TARGET_DEPENDS Resources)
	else()
...

Но все эти перспективные системы сборки убивает одно – непопулярность и выбор в пользу CMake, потому что он набрал большую массу пользователей. Даже Qt убил своё детище, под названием QBS и мигрирует на CMake по политическому бизнес-решению.

EXL ★★★★★
()
Ответ на: комментарий от hobbit

Дерево зависимостей модулей в Delphi/fpc, если что, там строится по директиве uses, которая синтаксически элемент языка, а не директива сбоку-припёки-препроцессора. Если uses выстроены правильно, значит, и порядок будет правильный.

Проект внезапно может состоять из файлов на разных языках программирования. В такой ситуации отдельная программа очевидно лучше.

Harald ★★★★★
()
Ответ на: комментарий от Harald

Проект внезапно может состоять из файлов на разных языках программирования. В такой ситуации отдельная программа очевидно лучше.

Да, может. Но это всё-таки не для всех проектов актуально, а там, где актуально — сложность внешних средств оправдана.

А «проектов одного языка» более чем дохрена.

Языкоспецифичные нашлёпки в последнее время рулят. К тому же языку Rust, например, сделали cargo. Да, это больше, чем просто сборочная система...

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от Harald

Если они их используют на уровне «дёрнуть статическую либу» — то это непринципиальное уточнение, там вся зависимость сводится к тому, чтобы вызвать линкер. Грязная работа уже сделана теми, кто саму либу собирал.

hobbit ★★★★★
()
Ответ на: комментарий от Deleted

Разработчик софта не может знать, куда его зависимости закинет судьба на волне очередного пакетного менеджера/контейнеризации/виртуализации/тупо компиляции под виндой. К слову, нынешние контейнеры в том числе были призваны решить проблему того, что разработчик не может и не хочет знать, как его софт будет собираться.
Вы спихиваете «ответственность за все грехи» то на разрабов симейка, то на писателей софта - а при чем тут они оба вообще? Создатели системы сборки делают язык и его минимальную реализацию под свои собственные задачи, дальше уже опционально - они не обязаны лично тебе гарантировать сборку. Создатель софта может захотеть написать послание потомкам на языке системы сборки, а может и просто слово из трех букв - у него все равно всё соберется. У тебя не собирается? Поставить другие библиотеки, почисть кэш, попрыгай с бубном, принеси жертву богам.

Тогда вылазят дистростроители, возмущаются тому, какой бардак возник, заявляют, что свобода должна насаждаться при помощи массовых репрессий. Делают свою систему сборки, унифицированные репозитории исходников и скомпилированных бинарников, пакетный менеджер для конечной установки. Потом это делают еще 10 организаций, и каждый снова сделал по своему, и каждого снова не волнует, как ты поставишь deb пакет на арче.

Тут можно навскидку придумать два выхода. Вариант проще: заставить всех под угрозой расстрела унифицировать среду, в том числе отказаться от классический виндовой организации. Вариант сложнее: сделать возможность легко и непринужденно адаптироваться к пакетным менеджерам; сделать инструмент для решения проблем сборки, и дать возможность использования результатов этого решения, не вынуждая собравшего софт пользователя делать десятикратную работу для дополнительного оформления своих результатов, как это имеет место в том же дебиане.

Мне, как и создателям мейкфайлов, кажется очевидным, что организация исходников, сборки софта на разных языках, установки/удаления/архивации/восстановления - это тесно связанный конвеер, где результат работы над одним модулем служит фундаментом для работы над другим. Отсутствие единого конвеера, языка и/или инструментов сопоставления шагов приводят к тому, что исходники больших проектов разработки софта окукливаются в неделимые сущности, намертво склеенные системой сборки конкретно этой софтины. Дистростроители же частенько после сборки софта делят его обратно на независимые логические сущности, как то основные исполняемые файлы, подключаемые библиотеки, доки, заголовки, отладочные инструменты.
На самом деле целые языки огораживаются от радости классический никсовой организации файлов: Python окукливается в pip, Haskell уже разделился на cabal и stack, даже Rust убегает в cargo, чтобы избежать проблем сборки сей.

Почему я не могу просто собрать параллельную версию базовых библиотек, и использовать ее для отдельных софтин? Потому что модель организации софта в никсах - это несколько мусорных контейнеров, в один из которых беспорядочно сваливаются бинарники, в другой - заголовки, в третий - библиотеки, в четвертый - доки.
Не поймите меня привратно - это замечательная модель... когда у вас на машине установлено полсотни софтин, ну максимум сотня. Нынче, когда любой крупный дистр содержит пакетный менеджер и тысячи пакетов, вообще нет причины для существования /usr/bin/ - это обратная совместимость, которой уже исполнилось полвека. Современная система организации софта, одновременно служащая системой сборки, должна сама находить имеющийся софт, сама находить библиотеки, заголовки, маны, потому что она их не теряла.
Устанавливаемый левыми сборщиками софт прекрасно отлавливается сборкой в отдельный корень или тупо по перехвату системных вызовов, как это делает paco. У нас конфликт библиотек? Просто поставим три версии онных с одинаковым релизным номером и разными опциями компиляции, пусть каждая софтина комплируется и работает со своей версией.

Давайте, скажите мне, что подобный проект уже был и он провалился.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Мало того, что оно тормозит саму сборку, так ещё и не умеет нормально параллелиться.

Это ты в рекламной агитке ninja или другого модного молодежного инструмента прочитал? make параллелит достаточно хорошо при подходящем -j. На лишние 0.5% всем насрать кроме упоротых фанатиков и балаболов, для которых это подходящая тема для болтовни на форуме.

anonymous
()
Ответ на: комментарий от EXL

Нужные библиотеки всегда в репу тащатся. И внезапно модуль из дистрибутива системы сборки не заработает с новой версией библиотеки(он о ней просто не знает).

Адекватная поддержка версионирования модулей могла был легко избавить разработчиков от этой проблемы.

Разве что по хэшу версии git/hg/etc, потому как версионность сборок нелинейна. Правда, как потом искать правильную версию - не совсем ясно. Тогда нужно встраивать продвинутые механизмы определения совместимости исходников, и версия сама по себе уже не играет роли.

Linux как-то живёт с этим, цветёт и пахнет, не забывай об этом

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

byko3y ★★★★
()
Ответ на: комментарий от EXL

Я просто хочу сделать в каком-нибудь абстрактном CMake что-то вроде:

Ну, и что тебе мешает это сделать? Или ты хочешь, чтобы все писатели библиотек все бросили и начали опакечивать свои библиотеки исключительно так как тебе хочется, чтобы тебе было удобно? И что ты сам сделал, чтобы реализовать свою хотелку?

В мире C++ нет дяди, который скажет, как правильно, поэтому существуют множество разных подходов, и часто они друг с другом не стыкуются. Одна из двух самых актуальных задач в C++ - управление зависимостями при сборке. И она не решена, однако, существует некоторое количество конкурирующих вариантов разной степени готовности, потому что задача эта не такая простая, как, например, написать очередную библиотеку и выложить ее на гитхаб или изображать из себя на форуме героя. Менеджер пакетов должен получать ту же информацию, что и система сборки, отсюда сразу следует, что либо это должна быть одна система, либо они должны обмениваться информацией (а, значит у них должен быть один автор, потому что разные авторы не осилят состыковать свои хотелки, т.е. все равно это должна быть одна система). Дальше - что делать с распространением собранных приложений, если приложение calculator зависит от libpng определенной версии, при этом в федоре установлена одна, в дебиане - другая, а у автора пакета заморочки по поводу сборки статикой… И еще туча других вопросов, которые нужно решить (например, сделать так, чтобы авторы пакетов опакетили свои поделки в подходящий пакетный менеджер).

В результате задача пакетного менеджера для C++ не решена. И ты можешь рассказывать про свои хотелки и какой ты д’артаньян, но это будет пустая болтовня. Или что-то сделать полезное для любого пакетного менеджера C++ (но, тогда никто не узнает, какой ты д’артаньян).

anonymous
()
Ответ на: комментарий от EXL

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

Синтаксис Makefile могут поменять, так чтобы новый make не собирал старые проекты и при этом никому не сообщить… Ты серьезно или просто поболтать?

anonymous
()
Ответ на: комментарий от EXL

CMake FindModules, pkg-config *.pc files, Android *.mk files, libtool *.la? files – какую ещё гадость и дрянь должны знать разработчики библиотек?

Забыл dockerfile, сейчас в современном софте без него никуда, иначе ты не современный, и не софт.

byko3y ★★★★
()
Ответ на: комментарий от hobbit

Избыточность той же cmake в том, что это — скриптовый язык, на котором можно писать В ТОМ ЧИСЛЕ сборочные последовательносте.

Вот только для того, чтобы читать и понимать скрипты cmake, не нужно знать его синтаксис (пока не потребуется что-то написать). С декларативщиной нихрена не понятно, пока не прочитаешь объемный мануал. При этом почти любая декларативщина в результате где-то будет содержать скрипты… Ну, и до кучи, автор каждой декларативщины изобретает свой синтаксис со своим набором непонятных закорючек и скобочек.

#
add_library( calcalator SHARED calculator.cpp )
#
calcatator: calculator.cpp
<TAB>@$(CC) $(CFLAGS) -o $(TARGET) $(TARGET).cpp
.PHONY: all
#
lib{calculator}: {hxx ixx txx cxx}{** -version} hxx{version} $imp_libs $int_libs
anonymous
()
Ответ на: комментарий от hobbit

Дерево зависимостей модулей в Delphi/fpc, если что, там строится по директиве uses, которая синтаксически элемент языка, а не директива сбоку-припёки-препроцессора

Я всё расскажу, я всё помню. Секция модуля от interface до implementation - это фактически заголовок файла, как заголовки C или генерируемый интерфейс в Java. Присоединение одного модуля другим - это использование именно интерфейса-заголовка. Если у тебя интерфейс использует другой интерфейс - получается вложенный интерфейс, один как бы содержит в себе второй. Именно интерфейсы создают некий ориентированный граф, сходящийся в главный модуль проекта. Не дерево, потому что один и тот же интерфейс можно включать в несколько интерфейсов.
Если у тебя есть скомпилированные модули, как то происходит со стандартной библиотекой и и прочими библиотеками, то в нем есть уже скомпилированный интерфейс, который компилятор может очень быстро прочитать и включить при компиляции разрабатываемых тобой модулей.
Самое веселое происходит, когда у тебя реализации двух модулей используют друг друга, при этом они оба не скомпилированы. Тогда компилятор берет интерфейс одного модуля, компилирует его, компилирует с этим интерфейсом второй модуль, а потом уже компилирует первый модуль со скомпилированным вторым. Это не запрещенный прием, и в этом случае порядок компиляции не определен - модули равнозначны.
Но два модуля - это ерунда, ведь можно сделать тысячу два модуля, где модули будут беспорядочно использовать друг друга, подключая огромные наборы еще не скомпилированных интерфейсов в очередном компилируемом модуле. Тогда у тебя будет не дерево, и даже не ориентированный граф, а просто клубок беспорядочных связей, которые периодически компилятор оказывается не в состоянии переварить.
True story.

byko3y ★★★★
()
Ответ на: комментарий от EXL

Разве компилятор/линковщик в Pascal / Delphi такой же тупой, как и ld из GNU Binutils / GCC и ему нужно давать пинок под зад (правильный порядок)

Паскалевому линковщику вообще безразлично, он просто всё в кучу закидывает. Я вообще удивлен, что GCC зачем-то нужен порядок.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Это ты в рекламной агитке ninja или другого модного молодежного инструмента прочитал? make параллелит достаточно хорошо при подходящем -j

Плюсану, но у ниндзи все-таки есть преимущества: https://david.rothlis.net/ninja-benchmark/
А именно - обновление уже собранного проекта занимает на порядок меньше времени в ниндзи. А по многопоточной сборке производительность одинакова.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Я вообще удивлен, что GCC зачем-то нужен порядок.

Эм…, всегда так было:

libavformat не видит libavutil (комментарий)

P.S. говорят, можно через -Wl,--start-group и -Wl,--end-group что-то там подшаманить, но вряд ли оно будет работать на старых ld.

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Менеджер пакетов должен получать ту же информацию, что и система сборки, отсюда сразу следует, что либо это должна быть одна система, либо они должны обмениваться информацией (а, значит у них должен быть один автор, потому что разные авторы не осилят состыковать свои хотелки, т.е. все равно это должна быть одна система).

У симейка есть фейсы для dpkg и rpm. Правда, они убогие.

Или что-то сделать полезное для любого пакетного менеджера C++

Или написать свой пакетный менеджер C++. Какие есть нынче перспективные любые пакетные менеджеры C++? Я думаю, что скорее самая пора пришла C++ закапывать.... наконец.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

В результате задача пакетного менеджера для C++ не решена.

И эта проблема может вконец понизить популярность C++ вкупе с C. Посмотрят программисты, которые захотели изучить современный C и C++, на эту CMake’овскую свалку из зоопарка разных FindModule’ей, делающих одно и то же дело, да и на саму проблему того, что нет стандартизированной сборочной системы, ужаснутся, да и уйдут на какой-нибудь Rust с удобным cargo.

Комитет он не зря с модулями закопошился. Как бы не орали староверы «нинужно», в комитете понимают, что если модули не завезти, все разбегутся.

Впрочем, посмотрим, что там в будущем нам светит. И как они будут решать проблему с зоопарком Linux-дистрибутивов да и компиляторов. Например, с C++ ABI эти проблемы до сих пор не решили.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от byko3y

Какие есть нынче перспективные любые пакетные менеджеры C++?

Выше уже писал: https://build2.org

anonymous
()
Ответ на: комментарий от byko3y

Или написать свой пакетный менеджер C++.

Вот, один уже написал на ЛОРе. Был бы толк. А толка не будет, пока это не стандартизировано должным образом.

Cross Platform Package Manager for C++

Какие есть нынче перспективные любые пакетные менеджеры C++?

Да куча их, см. в комментариях по ссылке выше.

EXL ★★★★★
()
Ответ на: комментарий от byko3y

Клубок беспорядочных связей - это инклуды в C/C++. Он вообще никем не контролируется, ведь это всего лишь директива препроцессора по включению одной простыни в другую. Это приводит к массе забавных последствий.

Например, забытый нужный модуль в uses автоматически приводит к ошибке компилятора. Поведение же компилятора в случае забытого #include в общем случае зависит от фазы Луны. Допустим мы ссылаемся на внешнюю библиотеку, а там один нужный заголовочник в одной версии включает другой, в другой нет. (Я не шучу, это реальная жизненная ситуация.) В итоге один и тот же вроде бы правильный код на одной платформе собирается, на другой нет, хотя используемая нами часть API не поменялась. А ещё есть стражи компилятора, которых тоже никто, кроме препроцессора не видит, и ошибки в которых тоже получаются довольно забавными...

uses, будучи элементом языка, а не сторонней нашлёпкой, в этом смысле куда строже.

Я ничего не имею против препроцессора как такового. Это очень мощная штука, которой можно творить мощные вещи. Но когда он используется для такой тривиальщины как имитация отсутствующей модульности — это забивание гвоздей микроскопом как она есть.

И да, мы от темы немного отклонились. Модульность языка и сборочная система — немного разные вещи. Но наличие в языке нормальных модулей уже даёт необходимый минимум информации для сборочной системы (кроме внешних зависимостей, конечно).

Паскалевому линковщику вообще безразлично, он просто всё в кучу закидывает

Вот не надо тут про кучу. К тому моменту, как в паскале вступает в дело линковщик, компилятор уже выстроил зависимости. Причём не так, как в сях, а детально — уже расписано, какая функция/класс из какого модуля берётся. В линковке осталось только эти связи в коде расставить. В сях же каждый объектник просто содержит два списка — объекты, торчащие наружу и неразрешённые имена. И линкер должен эти вещи друг с другом связать. В общем случае — методом тыка. К чему это может привести — я как-то уже рассказывал замечательную историю.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от EXL

А что, Kitware запрещают создание сommunity-driven-cmake-modules-collection? Обещают в суд подать если то самое коммьюнити что-то такое запилят?
Сдаётся мне что просто нахрен никому не нужно этим заниматься.
Как и Kitware.

WatchCat ★★★★★
()
Ответ на: комментарий от hobbit

Клубок беспорядочных связей - это инклуды в C/C++. Он вообще никем не контролируется, ведь это всего лишь директива препроцессора по включению одной простыни в другую. Это приводит к массе забавных последствий.

Истину глаголишь!

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

Сдаётся мне что просто нахрен никому не нужно этим заниматься. Как и Kitware.

Странное дело, раньше они этим занимались и хвалились, а теперь перестали. А в репозиториях зато появилась помойка из криво написанных FindModule’ей. Благодать прямо.

EXL ★★★★★
()
Ответ на: комментарий от EXL

а теперь перестали.

Всё меняется. Возможно переоценили свои силы.

Но ты не ответил, что мешает этому самому комьюнити организовать нормальный репозиторий модулей?

WatchCat ★★★★★
()
Последнее исправление: WatchCat (всего исправлений: 2)
Ответ на: комментарий от WatchCat

Я считаю, что это должно быть одобрено и поддержано (неофициально) самим Kitware. Возможно те, кто хотят создать подобное, тоже считают так же и ничего не делают.

Они сами накрутили фигни – пусть сами и сглаживают ситуацию.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Я считаю, что это должно быть одобрено и поддержано (неофициально) самим Kitware. Возможно те, кто хотят создать подобное, тоже считают так же и ничего не делают.

facepalm.jpg
Не, я понимаю, что лучше ныть в интернетиках и ждать доброго дядю, а на самом деле нахрен не надо да и тупо лень, а то давно бы уже появился и не в одном варианте.

WatchCat ★★★★★
()
Ответ на: комментарий от kuzulis

О, фанбои прибежали.
Если от QBS отказался основной разработчик, то существуют сомнения в будущем проекта.
А так-то умирать будет долго.

WatchCat ★★★★★
()
Ответ на: комментарий от anonymous

Это ты в рекламной агитке ninja или другого модного молодежного инструмента прочитал? make параллелит достаточно хорошо при подходящем -j. На лишние 0.5% всем насрать кроме упоротых фанатиков и балаболов, для которых это подходящая тема для болтовни на форуме.

@byko3y

А по многопоточной сборке производительность одинакова.

Ради интереса на коленке накидал простенький бенч и позапускал на холодную:

$ cat CMakeLists.txt 
file(GLOB SRC_FILES src/*.cpp)
add_executable(test ${SRC_FILES})

$ cat GenerateSourceFiles.py 
#!/usr/bin/env python3

import os, random

COUNT, DATA_X, DATA_Y = 1000, 10, 10

def huge_data(n):
    head = 'unsigned char table_' + n + '[] = {\n'
    for i in range(DATA_X):
        for j in range(DATA_Y):
            head += " " + str(random.randint(0, 255)) + ','
        head += '\n'
    head += '};\n\n'
    return head

def main_stub():
    return '#include "head.hpp"\n\n' \
           'int main() {\n' \
           '\tfunc_0();\n' \
           '\treturn 0;\n' \
           '}\n'

def header_stub():
    body = '#pragma once\n\n'
    for i in range(COUNT):
        body += 'int func_' + str(i) + '();\n'
    return body

def cpp_stub(i):
    return '#include <iostream>\n' \
           '#include "head.hpp"\n\n' \
           'using namespace std;\n\n' \
           + huge_data(str(i)) + \
           'int func_' + str(i) + '() {\n'\
           '\tcout << "Hello from func_' + str(i) + '()!" << endl;\n' \
           + '' if i < COUNT - 1 else '\tfunc_' + str(i + 1) + '();\n' + \
           '\treturn 0;\n' \
           '}\n'

if __name__ == '__main__':
    os.mkdir('src')
    for i in range(COUNT):
        with open('src/func' + str(i) + '.cpp', 'w') as file:
            file.write(cpp_stub(i))
    with open('src/head.hpp', 'w') as file:
        file.write(header_stub())
    with open('src/main.cpp', 'w') as file:
        file.write(main_stub())

$ ./GenerateSourceFiles.py

$ cmake -G"Ninja" .
$ time ninja -j4 > /dev/null

real    3m20.980s
user    11m58.253s
sys     1m9.719s

$ ls -A | grep -v "GenerateSourceFiles.py\|CMakeLists.txt\|src" | xargs rm -Rf

$ cmake -G"Unix Makefiles" .
$ time make -rR -j4 > /dev/null

real    4m21.200s
user    12m32.059s
sys     1m17.818s

Так что для меня теперь преимущество ninja стало ещё больше очевидно.

EXL ★★★★★
()
Ответ на: комментарий от WatchCat

Но ты не ответил, что мешает этому самому комьюнити организовать нормальный репозиторий модулей?

cmake - это система сборки (точнее генератор, но это мелочи), а не пакетный менеджер C++. Они понаделали костылей для поиска пакетов, но это костыли, а не полноценный пакетный менеджер. «Нормальный» репозиторий создать не получится одними силами cmake. Я как-то думал над созданием менеджера пакетов, который подгружает внешние пакеты, получая информацию о необходимых зависимостях от cmake. Но нужно сделать и подгрузку зависимостей и выбор наиболее подходящих версий пакетов во время работы cmake, а этого сделать не получится (по-крайней мере, за один проход). A хочет B и C, в свою очередь B хочет C, при этом менеджер зависимостей должен понять, какую версию C нужно закачать для A (до того, как он начал разбираться с зависимостями B), и она должна также подойти для B. Также нужно учесть, что зависимости могут зависеть от параметров сборки (A собирается с ENABLE_C зависит от C, а без него уже не зависит, хотя B будет требовать C всегда). Таким образом, для разрешения зависимостей нужно изначально знать весь граф целиком (с учетом параметров сборки).

Впрочем, соглашусь с тем, что тема упрощение разрешения зависимостей для cmake - скорее повод поговорить, чем что-то сделать.

anonymous
()
Ответ на: комментарий от WatchCat

Раньше, когда модули были в комплекте CMake, я был в зоне комфорта, а теперь – нет. Негодую справедливо.

EXL ★★★★★
()
Ответ на: комментарий от WatchCat

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

Conan для этого и сделан. Но там скорее настройка сборки (а не только зависимостей) делается в Python файле (где прописываются зависимости в виде кода на python), который генерит cmake (на самом деле там штук 5 вариантов только для cmake), который генерит Makefile, который собирает проект. IMHO, костыль на костыле, однако, это шаг в нужном направлении. Когда автор build2 поймет, что простота - залог успеха, будет сделан еще один шаг и появится менеджер пакетов C++.

anonymous
()
Ответ на: комментарий от EXL

Так что для меня теперь преимущество ninja стало ещё больше очевидно.

Как насчет поменять параметр -j {5,6,7}?

time make -rR -j5 > /dev/null
anonymous
()
Ответ на: комментарий от EXL

Непонятно, кому ещё в 2K20 году пришла в голову идея придумать такое уродство.

theNamelessOne ★★★★★
()
Ответ на: комментарий от anonymous
--- old.py      2019-04-18 15:29:52.582027224 +0700
+++ GenerateSourceFiles.py      2019-04-18 15:05:36.467992229 +0700
@@ -33,7 +33,7 @@
            + huge_data(str(i)) + \
            'int func_' + str(i) + '() {\n'\
            '\tcout << "Hello from func_' + str(i) + '()!" << endl;\n' \
-           + '' if i < COUNT - 1 else '\tfunc_' + str(i + 1) + '();\n' + \
+           + ('\tfunc_' + str(i + 1) + '();\n' if i < COUNT - 1 else '') + \
            '\treturn 0;\n' \
            '}\n'

Уф, я там косяк допустил в генераторе. Надо исправить, если кто-то будет запускать.

Как насчет поменять параметр -j {5,6,7}?

Вот с пятью процессами, больше особого смысла нет, у меня 2 ядра + 2 потока:

$ time ninja -j5 > /dev/null

real    3m22.168s
user    11m59.857s
sys     1m8.860s

$ time make -rR -j5 > /dev/null

real    4m3.034s
user    12m29.427s
sys     1m14.409s

Впрочем, я не уверен, что бенч «чистый», учитывая сколько там всякой пакости (цветная подсветка) в Makefile, которые генерирует CMake. Однако именно такими файликами и собирается большинство софта.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)

Почему не Bazel? Можно ставки делать, кстати, когда все ринутся на базель.

yoghurt ★★★★★
()

В месонской ложе ниндзи провели черную месу

anonymous
()
Ответ на: комментарий от byko3y

Самая длинная простыня, которую я здесь видел.

Вы спихиваете «ответственность за все грехи» то на разрабов симейка, то на писателей софта

Я не люблю абсолютизировать, поэтому ответственность за все грехи точно ни на кого не спихивал

они не обязаны лично тебе гарантировать сборку

Чёт кукаретингом завоняло, но ладно. И чо?

Давайте, скажите мне

Не, все же сформулируй нормально свою мысль, это я ниасилил

Deleted
()
Ответ на: комментарий от EXL

Так что для меня теперь преимущество ninja стало ещё больше очевидно.

Ты явно что-то не то мерил - это попросту невозможно.


[1002/1002] Linking CXX executable test

real    0m35,340s
user    3m48,306s
sys     0m28,886s

[100%] Linking CXX executable test
[100%] Built target test

real    0m35,772s
user    3m50,341s
sys     0m30,164s

[100%] Linking CXX executable test
[100%] Built target test

real    0m35,166s
user    3m50,180s
sys     0m30,173s


Единственное, что каким-то образом может внести разницу - это:

/usr/bin/cmake -E cmake_echo_color --switch= --green --progress-dir=.../build/CMakeFiles --progress-num= "Building CXX object CMakeFiles/test.dir/src/func100.o"

Но это никакого отношения к make не имеет.

NishiragiShintaro
()
Ответ на: комментарий от NishiragiShintaro

Проверил на другой тачке, получил следующие результаты:

$ time ninja -j2 > /dev/null
 
real    2m37.978s
user    2m13.124s
sys     0m18.124s

$ time make -rR -j2 > /dev/null

real    2m46.082s
user    2m19.012s
sys     0m19.696s

Видимо сильно влияют версии CMake, ninja, make:

Этот случай: CMake 3.5.1, Ninja 1.5.1, GNU Make 4.1
Случай выше: CMake 3.14.2, Ninja 1.9.0, GNU Make 4.2.1

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Случай выше: CMake 3.14.2, Ninja 1.9.0, GNU Make 4.2.1

GNU Make 4.2.1
cmake version 3.14.2
1.9.0.git.kitware.dyndep-1.jobserver-1

Видимо сильно влияют версии CMake, ninja, make:

Нет. У тебя явно какие-то проблемы. Потому что там тупо нет ничего, что даст хоть какую-то разницу. Там есть вызов cmake-рисовлки и вызов ещё тысячу раз даёт какое-то просядание копеечное, но это максимум.

Не может(вообще никак) пару сотен строчек скриптухи выполнятся 10секунд, минуты - это полная чушь.

NishiragiShintaro
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.