commit -m "better"

Forwarded from Kir S🕊️

🔥8😁4👍2👎1🤮1

1.08K views12:16

#bs #vendor #ix_run #dev_shell #gold

Меня удручает состояние современных OSS систем сборки. Расскажу сегодня про такой аспект: каждая уважающая себя современная система сборки хочет иметь в себе пакетный менеджер.

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

Cargo же все видели? Я пару раз писал, к чему приводит эта заявка на всеобъемлимость применительно к cargo - необходимость wrap все зависимости не под cargo в cargo сборку. Это выглядит уродливо, и приводит к проблемам с ромбоводными зависимостями.

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

Я уже писал про .wrap файлы от meson(для них существует целый репозиторий - https://mesonbuild.com/Wrapdb-projects.html).

Про это можно писать бесконечно, вот несколько очень всратых примеров:

* nodejs перепиливает сборочную систему от v8 на autoconf
* webkit переделывает сборочную систему от ANGLE(это реализация opengl от Google) на CMake
* chrome вендорит кучу библиотек, не буду описывать их по отдельности
* telegram вендорит все свои зависимости, и собирает их ни с чем не совместимым образом

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

Кстати, мне с этим живется несколько легче, чем там всяким fedora. В случае динамической линковки вендоринг - это еще и пересечение по путям в fs. В случае статической линковки это все хотя бы не видно наружу, достаточно де-вендорить всякие freetype/fontconfig и прочее.

Chrome, кстати, в этом отношении молодцы, они помогают де-вендорить те части, которые просто необходимо(типа рендеринга шрифтов).

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

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

Представьте себе команду

mix run lib/z lib/freetype bin/make 
    bin/cmake bin/clang/14 bin/ninja -- make -j 16

Эта команда сделает #realm , в котором будут доступны указанные библиотеки, указанные сборочные инструменты, и(вот тут важно!) врапперы для компилятора cc/c++/cpp (ну или rustc, кому что), которые автомагически настроят нужные пути к библиотекам и заголовочным файлам.

Кажется сложным? Ну давайте упростим это в alias mixrun=mix run $(cat mix.shell) —, и будем использовать так:

mixrun make -j 16

Или:

mixrun —sanitize=address —opt=-O2 make -j 8

Тогда в соответсвующем makefile вообще не нужно заниматься autodetect, перечислять всякие -I/-l-L/etc, а просто звать простые команды вида

cc -c x.o x.c

То же самое работает и для cargo, и для любой другой сборочной системы.

Основной point - система сборки уровня проекта не должна заниматься autodetect наличия зависимостей и их доставкой. Nix так умеет, Mix так умеет.

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

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

👍13

1.18K viewsedited 20:44