X.Org, ещё один проект отказывается от autotools

Я думаю голые Makefile дедов вполне устраивают. Сделать сборку в отдельную директорию там вполне можно.

ОКР надо лечить! Если пара файликов вызывает у тебя невыносимые страдания, то это плохие новости

Если пара файликов вызывает

Это не пара файликов, это хорошая такая тарелка лапши. Я бы даже сказал таз.

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

Открой для себя VPATH-сборки в Autotools. И не будет мусора в дереве исходников.

pkgconfig не умеет в поиск разных конфигураций (дебаг/релиз) в отличии от cmake

Вендопроблемы.

По мне разработка на C/C++ – это основной недостаток Windows. Там до сих пор практикуются прописывание абсолютных путей до библиотек в проектах и копирование библиотек в проект. Писать на C/C++ в UNIX-подобных системах намного приятнее.

The GNU Build System distinguishes two trees: the source tree, and the build tree. These are two directories that may be the same, or different.

The source tree is rooted in the directory containing the configure script. It contains all the source files (those that are distributed), and may be arranged using several subdirectories.

Fail.

с сайта pkg-config:

pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present

Кроме того, этот топик вроде как про meson. Ну так вот, meson предлагает писать внешние скрипты для кодогенерации. То есть shell-скрипты в онтопике и батники в винде. Кроссплатформенность 80 уровня…

Fail.

Чо?

Сгенерированный файл в директории исходников, а не сборки.

Сгенерированный файл в директории исходников, а не сборки.

Это часть инфраструктуры сборки, а не её результаты.

Это часть инфраструктуры сборки, а не её результаты.

Автор программы это писал? Нет. Значит никакая не часть. Это тоже самое, что сгенерированные Makefile и им место в директории сборки.

сгенерированные Makefile

…зависят от параметров сборки.

А configure - нет.

Автор программы это писал? Нет. Значит никакая не часть.

Ну тогда и png в архивы сорцов ложить не надо, пусть при каждой сборке конвертируются из svg заново. И файлы, выплюнутые bison. Пусть на всех системах стоит bison при сборке.

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

Маразм.

Глупость, впрочем, вполне характерная для тебя с твоим неумением различать уровни абстракций и их цели.

А configure - нет.

Ещё как зависят. В некоторых дистрибутивах его необходимо геренерировать.

Ну тогда и png в архивы сорцов ложить не надо, пусть при каждой сборке конвертируются из svg заново. И файлы, выплюнутые bison.

Всё верно. Например Mesa генерирует заголовки с регистрами видеокарт при сборке с помощью Python скрипта.

Пусть на всех системах стоит bison при сборке.

В чём проблема его установить? Он везде есть.

В чём проблема его установить?

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

Я даже не сомневался =)

Всё верно. Например Mesa генерирует заголовки с регистрами видеокарт при сборке с помощью Python скрипта.

Угу, в наше время всё делается при помощи питон-скрипта, даже небо, даже Аллах.

Угу, в наше время всё делается при помощи питон-скрипта, даже небо, даже Аллах.

Куда лучше лапши на Bash и Perl. Его хотябы читать можно, а не только write-only.

Он везде есть.

Задача не максимально зае… /вспомнил про политику модерации нынце/ …замучиться, а получить программу в пригодном для запуска виде.

Поэтому нет никакого смысла по стопицот раз генерировать то, что никак не меняется при сборках. Программа-генератор может отвалиться, сама неправильно быть собрана, быть не той версии, или вообще на дворе уже 2048-й, и 80% стека переписано.

Программы, для сборки которых нужен только компилятор C99 (а то и C89), make и sh, сейчас собираются ровно как 20 лет назад. А где через 20 лет будет ваш питон, для сборки которого самого нужна отдельная экосистема рабочего софта, увидим.

Принцип минимальной достаточности.

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

Компилятор в отдельном пакете вообще то. И он никак не зависит от собираемого им проекта в отличии от configure.

Его хотябы читать можно, а не только write-only.

Мвахаха! Это ты говоришь человеку, который постоянно пишет на питон?

Охренительно на нём можно писать и читать!

class оч_нужная_херня(object):
    def шняга(self, конь_в_пальто=None):
        ехал
            грека
                через
                    реку
        видит
            грека
                в
                    реке
                        рак
        сунул
            грека
                руку
                    в
                        реку
        угадай
            где
                кончается
                    какой
                        блок
                            цуко

Я тут давича правил код, в котором перед концом функции было шесть отступов! Шесть! Сраных! Отступов!

Скажи мне больше о питоне, это мы еще про семантику не начали говорить!

И он никак не зависит от собираемого им проекта в отличии от configure.

configure никак не зависит от окружения сборки проекта.

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

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

Программа-генератор может отвалиться, сама неправильно быть собрана, быть не той версии

Это где такое? Даже на Haiku таких проблем нет. Выход Bison без проблем пересобирается. Он используется например в компиляторе ресурсов Haiku.

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

Я делал полную пересборку всего когда делал порт Haiku на RISC-V и Python не был большой проблемой. Наибольшей проблемой как всегда были Craptools. Там что-то сломалось что пришлось половину генерированных файлов патчить. Благо патч однообразный. Починилось кажется с обновлением Bash.

И после этого меня еще спрашивают, как я пишу на JS.

С чувством облегчения пишу!

4.2 Ещё как зависит если не используются популярные дистрибутивы. Не даром в Craptools куча костылей для разных дистрибутивов. С таким подходом не мудрено что потребуются ещё костыли.

Я настраиваю табуляцию два пробела. Мне норм. После лесенки IF в Обероне ерунда.

Я настраиваю табуляцию два пробела.

Меня б еще кто спрашивал о стиле кода в проекте =)

Это в редакторе кода настраивается. У GNUтого кода вообще 8 пробелов.

Это никак не поможет обозначить концы блоков.

Боже, я мечтаю о мейнстримном языке, в котором компилятор бьёт по рукам, если не пишешь «end if», «end for» и т.п., то есть обязан явно обозначать не просто конец блока, но и его тип.

А писать приходится на ЭТОМ.

Кстати sh в этом отношении великолепен.

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

Это никак не поможет обозначить концы блоков.

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

Возьмите редактор кода с поддержкой Python

А если я код на гитхабе, на форуме, в выхлопе gitk и т.п. смотрю, мне его тоже грузить в «редактор с поддержкой Python»?

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

«Большая часть программистов» еще и программировать не умеют. И я в их числе. Но я в отличие от многих ясно осознаю, что я лох, и что мне для написания грамотного кода нужна максимальная помощь со стороны дизайна языка.

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

А потом эта задача приходит ко мне, а в ней километровый JS-файл, в котором уровень вложенности кода по 10-12 элементов, и одна функция включает в себя по стопицот вложенных лямбд. Или вот питон с безумными отступами.

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

Вот результат ваших «простых и удобных ЯП», которые «не вызывают сложностей».

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

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

if
    .
    .
    .
    .
    .

if
    pass
else:
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    try:
        .
        .
        .
        .
        .
        for
            .
            if
                .
                .
                .
                for
                    for
                        .
                        if
                            for
                                for
                                    if
                                        for
                                            if
                                                .
                                                .
                                                if
                                                    .
                                                    .

        .
        .
        .
    finally:
        .
        .
        for
            .
            try:
                if
                    .
            except
                pass

/bolit/system/lib/libroot.so

Так наверно

Там опечатка. На самом деле /boot/system/lib/libroot.so. /boot – это куда монтируется диск с системой. Корень ФС хранится в памяти и там нельзя создавать файлы.

Корень ФС хранится в памяти и там нельзя создавать файлы.

В ПЗУ вестимо.

В RAM специальной ФС rootfs. Там можно создавать только директории и символьные ссылки. После перезагрузки всё сбрасывается.

pkg-config не работает с нативной экосистемой Windows, предлагается обмазываться MinGW’ами, MSYS’ами или ещё какой-нибудь штукой, pkg-config не работает нормально с тем же Android и iOS. Да и с macOS не очень.

Кроме того, этот топик вроде как про meson. Ну так вот, meson предлагает писать внешние скрипты для кодогенерации. То есть shell-скрипты в онтопике и батники в винде. Кроссплатформенность 80 уровня…

Но речь в этом топике шла про сравнение его с другими системами сборки или генераторами сборочных рецептов. Я соглашусь, что у Meson пока слабо развита кроссплатформенность вне Linux вообще, особенно в сравнении с autotools или CMake. Но в данном случае речь идёт про CMake, который заявляет об этой кроссплатформенности но на деле работает как говно, потому что дегенераты разрабатывающие CMake сначала хотели принимать FindModules в дистрибутив CMake, а потом поменяли своё решение отказавшись это делать, но при этом все эти модули не удалили, а заморозили. В итоге форменная неконсистенция: одни библиотеки по дефолту распознаются вроде SDL 1, а к другим нужно писать эти говномодули.

Разработчики CMake неосилили начатое ими хорошее начинание и поступили подло, прямо как RedHat, который скостил срок поддержки у CentOS 8 с 2030 года до 2021. Читай, нарушили данное ими обещание.

Засорение исходников проектов полурабочими FindModules, которые теперь вынуждены каждый раз писать прикладные разработчики целиком на совести идиотов из Kitware.

pkg-config не работает с нативной экосистемой Windows

Так там и экосистемы пакетов нет. install.exe

Билд-системы сишки у меня всегда вызывали лютое недоумение.

Да тут у нас вообще ужас. Вот казалось бы, после того обосрамса CMake, когда они нарушили свои обещания и перестали бандлить модули поиска 3rd party библиотек, сообщество C/C++-разработчиков могло бы организовать какой-нибудь централизованный репозиторий, в который бы выкладывали FindModules к популярным библиотекам. Да чёрт с этим сообществом, сами разработчики CMake из Kitware могли бы сделать такой репозиторий отдельно под официальной эгидой, могли бы предоставить возможность сообществу, пользователям CMake и всем желающим добавлять и дорабатывать эти модули. Но хрен там стоял.

Разработчики CMake жидко обделались на публике, а публика теперь вместо того чтобы выкинуть их говноподелку на мороз, засирает GitHub и свои проекты вот этим вот говном: [1], [2], [3], [4], [5], тысячи их и все полурабочие и недоделанные.

Типичный путь программиста на C и C++, который использует CMake и хочет подключить какую-то 3rd party либу вроде SDL2_mixer, прямо как у какого-нибудь эталонного бомжа начинается с хождения по помойке (GitHub), разработчик ныряет в мусорки других бомжей (GitHub-репозитории) в поисках уже готовых «вкусняшек» (CMake-модулей). В другом случае разработчик должен садиться и писать эти велосипедные говномодули самостоятельно, чтобы решить элементарнейшую для 2021 года проблему подключения 3rd party библиотеки в проект. Какого качества будут эти велосипедные модули отлично продемонстрированно по ссылкам выше.

И после этого люди задаются вопросом «Чем плох CMake?», лол. И после этого у них ещё хватает совести ругать всякую Java где нужная библиотека добавляется вообще элементарно строчкой:

implementation 'com.formdev:flatlaf:1.6'

Или вообще из любого GitHub-репозитория:

allprojects {
    repositories { 
        jcenter()
        maven { url "https://jitpack.io" }
    }
}
dependencies {
    compile 'com.github.User:Repo:Tag'
}

Да, пусть оно минуту-другую «жужжит SSD» и долго запрягает, но на выходе я получаю готовое решение а не findmodule’ные пляски как в CMake.

Открой для себя vcpkg.

Никаких самописных модулей Cmake тебе больше не понадобится.

Так там и экосистемы пакетов нет. install.exe

Давно же тебя в Windows не заносило:

https://vcpkg.io/en/index.html
https://habr.com/ru/company/microsoft/blog/560254/

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

Открой для себя vcpkg.

Никаких самописных модулей Cmake тебе больше не понадобится.

Собственно, я всегда подозревал что импотенцию различных фанатиков и разработчиков CMake пофиксит именно Microsoft, причём не только под свой Windows, но и под другие OS. Единственное жаль, что CMake они на мороз из vcpkg не выкинули. А ведь разработчики Microsoft могли бы запросто написать что-то более адекватное ему на замену. Возможно бы это даже взлетело.

Причём тут вендопроблемы?

Не встречал бинарные пакеты с разными конфигурациями в Линуксе и прочих UNIX-like системах.

2021-й, Карл. Таки да, я успел состариться, а в винде появился пакетный менеджер.

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

И что тогда делать(

ругать всякую Java где нужная библиотека добавляется вообще элементарно строчкой

Ну вот тут ты не совсем прав, разрешение конфликтов зависимостей в яве это довольно вкусно. Но в целом да, все так

Меня больше смущает что с сишкой когда нашёл баг в либе невозможно взять её исходники с гитхаба, всунуть в ide, отдебажить, поправить и вернуть обратно в виде PR не потратив полдня на билд конфиг и его импорт в ide. И даже если один раз таки сесть и разобраться, то с другой либой все эти круги ада нужно проходить заново

А, тогда ок. Обычно вся жесь в libtool вылезает.

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

Пока ещё не сделали. Типичные виндопроблемы перевешивают типичные линуксовые проблемы.

всунуть в ide

в какое еще ide

https://habr.com/ru/company/microsoft/blog/560254/

Это, не тот ПМ, который тупо на все «хотите мы установим вам ххх» просто отвечает согласием?