Git 2.48

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

УМВР. Может Muon криво собран?

А, разобрался: ему надо PKG_CONFIG_PATH=/usr/local/share/pkgconfig выставить, а мезон, похоже, сам умеет нестандартные префиксы добавлять в пути.

Проблема, видимо, в libpkgconf. По тому как сам pkg-config в /usr/local/share/pkgconfig смотрит и без всяких танцев с переменными…

Ну у мезона-то всего 1 зависимость: питон. Не знаю, много это, или мало…

Это слишком много. Питон гораздо больше чем мезон. Это принципиально неверно. Я, конечно, мезоном не пользовался, но если это хорошая штука, то жаль… Будем надеяться что мюон взлетит!

Я, конечно, мезоном не пользовался, но если это хорошая штука, то жаль…

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

Будем надеяться что мюон взлетит!

Я против такого велосипедостроения. У самого мезона-то катастрофическая нехватка инженерных сил. А тут ещё кто-то решил распылять силы на его реплику… Питон перепиши на плюсах, да влинкуй в мезон, если зависимость от питона глаза мозолит. Даже гуглить не охота, но уверен, что таких решений полно.

Сконструировать более убогонький DSL, чем тот который высрали наркоманы из Kitware это надо уметь.

Gradle сумел!

Сперва ты пишешь sources := src/*.c, потом ты пишешь filter-out на один файл, потом на два, потом на другой wildcard, потом разбираешься, почему чего-то не хватает в сборке. Ничего хорошего в этом нет. Явно перечислить файлы ручками не обломаешься.

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

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

Управления чем?

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

Итого это безосновательная шиза. Как раз синтаксис у meson более чем удобный. После CMake портянок небо и земля.

Нет уж сударь, кушайте сами.

Я против такого велосипедостроения. У самого мезона-то катастрофическая нехватка инженерных сил. А тут ещё кто-то решил распылять силы на его реплику… Питон перепиши на плюсах, да влинкуй в мезон, если зависимость от питона глаза мозолит. Даже гуглить не охота, но уверен, что таких решений полно.

Логично предположить что разработчики мезона переключатся на мюон, зачем нужен мезон, если есть мюон? А если не переключатся, то это плохой сигнал.

А как вы любите мержить в master?

1. merge commit
2. squash + fast-forward merge
3. rebase + fast-forward merge
4. просто fast-forward merge (заставляет ребейсить локально, в GitHub, GitLab, Azure DevOps не поддерживается)

Лично мне ближе 4-й вариант, поскольку он самый чистый.

Как вы относитесь к любителям мержить не так как вы?

А как вы любите мержить в master?

Не представляю что это за варианты, всегда делаю просто git push --force

Криптографические уязвимости из него уже убрали, или лучше пользоваться Mercurial-ом?

Я не совсем понял, что такое merge commit?

Я прости иду в мастер и делаю «git merge my-branch». Это какой номер? Первый?

Я не совсем понял, что такое merge commit?

Коммит в master, у которго два предка - предыдущий коммит в master и последний коммит в твоём бранче.

Я прости иду в мастер и делаю «git merge my-branch». Это какой номер? Первый?

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

Не представляю что это за варианты, всегда делаю просто git push –force

Прямо в master?

Нафиг нужен этот мюон?

Ну, ему даже Ninja не нужна, если скомпилировать с интеграцией samurai.

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

Вы прикалываетесь? Вы много раз видели, чтобы разработчики переключались бы на форк своего проекта? Особенно на такой, где нет последних ихних фичей.

У Meson не сильно то лучше синтаксис, там где на CMake можно написать относительно лаконичный скрипт, то у Meson - это будет длинная портянка.

Всем им далеко до tup:

CFLAGS += -Wall
CFLAGS += -O2
: foreach *.c |> gcc $(CFLAGS) -c %f -o %o |> %B.o
: *.o |> gcc %f -o %o |> hello

И встроенная Lua:

function compile(source, output)
	tup.definerule{ inputs = {source}, command = 'gcc %f -o %o', outputs = {output} }
end

compile('hello.c', 'hello')
compile('goodbye.c', 'goodbye')

Как попробовать самурай?

Ну вот попробовал с STC 5.0.

$ muon setup build
$ cd build
$ muon samu

Всё пучком.

Когда же в Git можно будет добавлять пустой каталог (как в SVN)…

Когда же в Git можно будет добавлять внешний файл (как в SVN), а не только внешний каталог…

Ага, так это замена нинжи? Ещё 1 лисопед? Так бы и говорили. :) Я-то думал, он всё сам соберёт, без генерации промежуточного кода. Однако это, похоже, работает. Сборка полностью мюоном - не проходит. Но если сгенерить нинжу мезоном, а потом натравить на это самурая - тогда собирается! :)

Сборка полностью мюоном - не проходит.

У меня muon-git.

$ muon setup -D samurai=enabled build
$ cd build
$ muon samu

Всё собирается.

Всё собирается.

Да я тыкаю проект (из соседнего топика, кстати), у которого в meson setup указывается –cross-file и –native-file. Мюон эти опции вообще не понимает, так что не удивительно, что у меня он и не собирается. Как их мюону передать?

Как их мюону передать?

Нашёл: muon meson setup <meson_opts> (да-да, именно muon meson). Но потом всё равно сборка разваливается.

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

Какими проблемами? Вроде до сих пор проблем не было. И при чём тут пул реквест, если гитхаб не используется? Это же способ организации работы в гитхабе, а мы говорим про гит. Разве в гит есть пул реквест?

Вы прикалываетесь? Вы много раз видели, чтобы разработчики переключались бы на форк своего проекта? Особенно на такой, где нет последних ихних фичей.

Я просто не вижу будущего за системой сборки не питоне. Питон хорош для прототипа. Они добились чего-то рабочего, но нельзя же всё время пилить прототип…

там где на CMake можно написать относительно лаконичный скрипт

Кстати, есть такая штука: https://github.com/build-cpp/cmkr.

# $ cat cmake.toml
[project]
name = "hello_world"

[target.hello_world]
type = "executable"
sources = ["*.cpp"]

$ cmkr gen генерирует пару файлов. Вот такой CMakeLists.txt:

# This file is automatically generated from cmake.toml - DO NOT EDIT
# See https://github.com/build-cpp/cmkr for more information

cmake_minimum_required(VERSION 3.15)

if(CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
        message(FATAL_ERROR "In-tree builds are not supported. Run CMake from a separate directory: cmake -B build")
endif()

set(CMKR_ROOT_PROJECT OFF)
if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_SOURCE_DIR)
        set(CMKR_ROOT_PROJECT ON)

        # Bootstrap cmkr and automatically regenerate CMakeLists.txt
        include(cmkr.cmake OPTIONAL RESULT_VARIABLE CMKR_INCLUDE_RESULT)
        if(CMKR_INCLUDE_RESULT)
                cmkr()
        endif()

        # Enable folder support
        set_property(GLOBAL PROPERTY USE_FOLDERS ON)

        # Create a configure-time dependency on cmake.toml to improve IDE support
        set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS cmake.toml)
endif()

project(hello_world)

# Target: hello_world
set(hello_world_SOURCES
        cmake.toml
        hello_world.cpp
)

add_executable(hello_world)

target_sources(hello_world PRIVATE ${hello_world_SOURCES})
source_group(TREE ${CMAKE_CURRENT_SOURCE_DIR} FILES ${hello_world_SOURCES})

get_directory_property(CMKR_VS_STARTUP_PROJECT DIRECTORY ${PROJECT_SOURCE_DIR} DEFINITION VS_STARTUP_PROJECT)
if(NOT CMKR_VS_STARTUP_PROJECT)
        set_property(DIRECTORY ${PROJECT_SOURCE_DIR} PROPERTY VS_STARTUP_PROJECT hello_world)
endif()

Я просто не вижу будущего за системой сборки не питоне. Питон хорош для прототипа.

Да вы что, троль? Питон используется в продакшне повсеместно. Другое дело, что чел приводил здесь пример бутстрапа дистрибутива, где, возможно, неудобно питон таскать. Но есть полно решений, позволяющих сделать из питоновской проги бинарь. Эти решения простираются от компиляции и статической линковки до контейнеризации, но результат один: бинарь без зависимостей. Проблемы-то нет.

Да вы что, троль? Питон используется в продакшне повсеместно.

Повсеместно, кроме бутстрапа систем сборок для сей, плюсов и прочих LFS.

Но есть полно решений, позволяющих сделать из питоновской проги бинарь.

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

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

Генератор для смейк, который генератор для мейк/нинзя? Отлично :)

Вообще хотелось бы видеть что-то адекватное с описательной частью на ini-подобном языке и скриптотой на Lua DSL.

На моей памяти был ini-подобный qmake, но там какой-то мрак и ужас когда пытаешься вставить строки.

Ещё были основанные на Lua - premake и xmake. Premake вроде как давно в полузаброшенном состоянии, а автор xmake, когда я его смотрел, гнался за хайпом и вкладывал в архитектуру неверные решения, по крайней мере мне так показалось, когда он выпускал свои первые презентации.

Premake вроде как давно в полузаброшенном состоянии

С чего это? v5.0.0-beta4:

2 weeks ago

Вы чо, прикалываетесь? Какой минимум исходников у компилятора, вы гцц собирали когда нибудь? Это процедура на часы! И зависимостей у него полно, правда он их сам собирает ЕМНИП. Так питон и месон намного меньше всей этой махины. И отлично утромбуются в бинарь без зависимостей. Скажите спасибо что это не базель - тот, емнип, вообще ждк за собой тянет. А тут всего лишь питон. :)

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

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

А что там с ninja, добавили поддержку?

Нет, но есть сторонний модуль: https://github.com/jimon/premake-ninja.
Правда, там много ToDo. Я не пробовал.

они выбрали питон и не слезут с него

Тогда симейку бояться пока нечего.

Спорное утверждение. С 1й стороны, месон много чего не умеет, и по тому, может и так. С другой - переход на него довольно таки массовый. Так что симейк уже много пользователей потерял. Но, при текущем состоянии дел, полной его маргинализации пока не предвидится.

С другой - переход на него довольно таки массовый.

А откуда дровишки? Я вот погуглил статистику - не нашёл. Может ты какую-то видел? В Интернетах всё ещё ссылаются на симейк, как на стандарт, мезон упоминают вместе с другими сконс, базель и т.п. Даже не на втором месте.

Пусть лучше так, чем встраивать интерпретатор питона в сборочную систему…

• Было: сборка требует наличие Python

• Стало: сборка требует наличие CMake и Python

Каким образом это «лучше»? Почему бы не избавиться от ограниченности и убогости CMake, раз проектам по типу Blender и Telegram потребовалась гибкая конфигурируемость средствами Python?

У вас какой-то пунктик насчёт этого самого Python? У меня тоже к нему очень много вопросов по части самых разных несуразностей.

Однако, я меня есть силы признать, что сегодня интерпретатор Python’а идёт ИЗ КОРОБКИ в абсолютном большинстве дистрибутивов Linux и даже в macOS. Вот прямо как говорят «с завода». И даже в Windows его вроде как кладут сразу в систему.

Тогда как CMake везде нужно «доустанавливать». Так что я не понимаю ваших претензий вообще по части бутстрапинга, если учитывать что тот же CMake из исходников собирается в несколько раз дольше чем интерпретатор современного Python + Meson + Muon + сам проект.

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

Ещё раз: минимум исходников с минимумом зависимостей это не про CMake. Он собирается дольше/сравнимо с GCC из-за огромного количества C++ вороха в нём, тогда как компиляция интерпретатора того же Python на чистом C пролетает буквально за несколько минуток.

Какой минимум исходников у компилятора, вы гцц собирали когда нибудь? Это процедура на часы! И зависимостей у него полно, правда он их сам собирает ЕМНИП.

CMake-ссанина, кстати, сегодня собирается дольше/сравнимо с GCC. Да, наркоманы из Kitware настолько раздули свой приплюснутый говнокод, что окружение Python + Ninja + Meson с нуля вместе с последним интерпретатором Python собирается быстрее чем их CMake детище.

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

Полностью согласен. Система сборки в первую очередь должна быть удобной для разработчика. Но когда она начинает вставлять палки в колёса и в папочке «cmake» начинаются спавнится Python-скрипты потому что CMake – форменная ущербность:

https://github.com/desktop-app/cmake_helpers/tree/8c146a3ec6f4475e5083eee84d126960495a7e1d

То это значит что проект вышел на тропу войны с самой сборочной системой и её выбор был изначально неверным.

А откуда дровишки? Я вот погуглил статистику - не нашёл.

А ты загляни в сорцы современного Linux-стека. Базовые кирпичики-компоненты по типу GLib, X.Org, Wayland, systemd, GTK+, GStreamer, все приложения GNOME и многие другие штуки собираются сегодня именно Meson’ом. Теперь вот и Git к ним добавился.

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

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

Если autotools был позором проекта GNU, то CMake это позор в первую очередь C и C++ разработчиков. Непонятно по какой причине негласным «стандартом» был выбран откровенно виндузотный проект врачевателей (!!! даже не программистов !!!), которые нашкодили хлама в лучших традициях MSVC Windows, наплевав даже на те устоявшиеся правила в UNIX-like по типу make V=1 и пр. Даже Google в Android заботливо перенёс такие штуки в свой местный ndk-build.

CMake полностью инороден для привычного UNIX-like инструментария и заставляет пользоваться программистов абсолютно шизотипическим нелогичным DSL, при использовании которого возникает закономерный вопрос – а его вообще проектировали и обсуждали? Или оно само так выросло? Без админ-ресурса по продвижению CMake со стороны всяких Microsoft и прочих тут явно не обошлось.

Ну не могли же просто так наши любимые C и C++ разработчики, далеко ведь не глупые люди! Не только перейти на такое вот убогое безобразие, но и обмазывать его потом Python-скриптами и считать это нормой.

А откуда дровишки?

Ну, как минимум, весь гном и всё, что с ним связано, на него перешли. А это уже не мало. Потом, я стал всё чаще с ним сталкиваться в реальной жизни: тот же кему уже его использует, и многие другие проги, которые я собираю/запускаю. При том, что, ещё пару лет назад, я о нём вообще не слышал. Так что тот факт, что он, в принципе, взлетел - для меня очевиден. Но это лишь моё мнение, основанное на личных наблюдениях. Я полагаю, статистику мог бы подбить кто-нить из дебиан - там ведь они много пакетов собирают. Но таки да, почему-то статистика не гуглится.

Есть и «отрицательные» внедрения. К примеру, в либреоффис его так и не пропихнули.

Было: сборка требует наличие Python Стало: сборка требует наличие CMake и Python Каким образом это «лучше»? Почему бы не избавиться от ограниченности и убогости CMake, раз проектам по типу Blender и Telegram потребовалась гибкая конфигурируемость средствами Python?

Нет, было в 99% cmake/make/autotools и в 1% случаев + «что-то». Причём на месте «что-то» может быть что угодно. Нет никакой привязки к питону.

если учитывать что тот же CMake из исходников собирается в несколько раз дольше

Какая разница, сколько он там собирается? Десяток секунд туда-сюда ни на что не влияют. Дело не во времени сборки. Тем более что он не собирается долго.

Он собирается дольше/сравнимо с GCC

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

У вас какой-то пунктик насчёт этого самого Python?

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

Ну, как минимум, весь гном и всё, что с ним связано, на него перешли. А это уже не мало.

Это вообще что-то стремящееся к нулю.

Так что тот факт, что он, в принципе, взлетел - для меня очевиден.

Миру нужна хорошая сборочная система, способная стать новым стандартом, а не то что смогло просто «взлететь». Сборочная система способная стать стандартом должна отвечать на все проблемы лучше или не сильно хуже того что уже есть. А так новые сборочные системы, которых довольно много наплодили (билд2, сконс, базель и прочие, вроде их десяток), только ухудшают ситуацию. Если мезон не сможет заменить во всех случаях остальные системы, то лучше бы он не взлетал, потому что теперь когда я приду в новый проект, мне придётся ещё и с ним разбираться. Ну и зачем мне такое счастье, если и симейка хватает за глаза.

Тогда симейку бояться пока нечего.

Тем временем SQLite Release 3.48.0 On 2025-01-14:

Autosetup is now used instead of GNU Autoconf.

угу, авто* семейство никуда не делось, симейк его не смог заменить

Миру нужна хорошая сборочная система, способная стать новым стандартом

Может, таковая уже родилась?

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

Вы путаетесь в показаниях. Если она способна (лет через 10) стать стандартом или эталоном, то сейчас, на данный момент, ей нужны совершенно другие качества, чем те, которые будут у неё тогда, когда она им таки станет.

только ухудшают ситуацию.

Борятся за жизнь и выясняют, кто же из них способен стать стандартом.

Если мезон не сможет заменить во всех случаях остальные системы, то лучше бы он не взлетал

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

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

Не думаю. Если вы пришли в новый проект, то вам придётся, максимум, добавить 1-2 файлика в список имеющихся сурсов. Это не трудно сделать. Разбираться пришлось тем, кто, до вас, портанул проект на месон с какой-то другой системы сборки.

Ну и зачем мне такое счастье, если и симейка хватает за глаза.

Если вам его хватает, вас кто-то заставляет переводить свой проет на него? Когда я говорил, что симейк теряет пользователей, то я имел в виду - потенциальных. Которые переходят на мезон, а не на симейк. Это не значит, что все ломанулись, или в будущем ломанутся, с симейка валить на мезон. Просто если все новые проекты будут сразу на мезоне делаться, то симейк и сам постепенно скопытится.

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

Так и что ты имеешь против Python’а и любого другого нормального скриптового языка в качестве сборочной системы? Тем более что он идёт из коробки сразу в современных дистрах?

Практика последних лет и куча дерьмовых скриптов в папках cmake крупных проектов показывает, что разработчикам для сборочной системы нужен нормальный script-like язык, а не обрубыш-DSL вроде CMake на котором скриптовать сценарии сборки сплошная боль.

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

Логика очень простая, никому не нужно 10+ несовместимых (недо)сборочных систем, в принципе одной достаточно.

Ну ладно, пускай их будет 10 или 20, как компиляторов с/с++, но они все будут при этом +- совместимы, как совместимы компиляторы благодаря стандарту на с/с++.

Логика очень простая, никому не нужно 10+ несовместимых (недо)сборочных систем, в принципе одной достаточно.

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

Ну ладно, пускай их будет 10 или 20, как компиляторов с/с++, но они все будут при этом +- совместимы, как совместимы компиляторы благодаря стандарту на с/с++.

Да это полный бред. Как вы сделаете их совместимыми, если какая-то ориентирована на скорость сборки, другая - на как можно более широкий охват таргетных платформ, третья - на гибкость и универсальность, четвёртая - на интеграцию в айдиешки, пятая - просто идёт по дефолту с данным языком и его тулчейном, и тд? Это всё равно, что сказать: пускай будет 20 языков программирования, но все они будут совместимы… Но что-то вот они не все совместимы… точнее, языки вообще все не совместимы между собой (кроме частичной поддержки Сей плюсами), но вас почему-то это не смущает. А вот системы сборки подавай все совместимые, ага. Ну пилите свою мюон, что ещё тут скажешь. Только что-то у меня складывается ощущение, что вы вообще не в теме, либо «тонко» тролите.