Деградация в opensource?

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

Если ты имеешь в виду деградацию простоты сборки — то да.

Ну когда на вики в разделе сборка пишут, что надо править файлы cmake, а затем идет раздел «Fixing cmake errors », я даже не знаю, как это правильно называть. По-моему, это просто за гранью

Знаешь, минута гугла на телефоне перед сном поведала мне что под арч есть pkgbuild, есть несколько ppa к бубунте и есть несколько замшелых rpm под федору и сузю. Зачем ты собираешь сам? Не, если гентушник - ок, без проблем, сам такой. Иначе зачем?

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

А это не только luxrender касается.

Собрать в своей системе самый свежий или наоборот староватый софт из авторских сырцов часто стало очень трудным делом.

я даже не знаю, как это правильно называть

Это называется «посмотри дату последней модификации страницы».

Да там почти вся информация старая. Новая получается из чтения cmake файлов. Если бы в дефолтном варианте сборки хотя бы собирался беспроблемно, не было бы претензий.

собирался беспроблемно

build-64-sse2 не работает?

luxrays по дефолту требует embree с поддержкой bvh (embree2/rtcore_bvh_builder.h), который надо отдельно искать, т.к. стандартная embree его не содержит, а также в cmake файле не прописаны все необходимые пути, откуда брать заголовки, что при сборке приводит к проблемам вида

luxrays/ui/luxrender2/aboutdialog.cpp:24:28: фатальная ошибка: ui_aboutdialog.h: Нет такого файла или каталога

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

а еще у luxrays нет make install

Деградация названий топиков на LOR.

Да там почти вся информация старая. Новая получается из чтения cmake файлов.

ну так пойди и обнови вику. у нее вообще есть прикольная фича: каждый может пойти и написать «правильно».

luxrender != весь opensource. А opensource это принцип, в первую очередь, а не сам софт. ОП-пост - говно. /thread

Светоч ЛОРа начала 2000х Виталий Светославович Луговский был против усложнённых способов сборки, в пользу простого скрипта build.sh.

Посмотрел как в арче собирают. Вроде дефолтный ембри берут.

Многие крупные проекты на самом деле собираються довольно не тривиально. И это нормально, специфика разработки ПО - если писать нативный код, завязанный на много сторонних библиотек, то невозможно все предусмотреть. Берите собранное, если сами не можете.

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

Деградация в opensource?
На примере одного интересного проекта.
одного

Ясно.

Это всё из-за выбора cmake, не иначе. Вот собирался бы сабжевый проект автотулзами, никаких проблем бы не было.

Вот кто-нибудь жалуется на ЛОРе на проблемы со сборкой, к примеру, syst*md? То-то же :)

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

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

автотулзами

Автотулзы можно с Ninja подружить?

Автотулзы можно с Ninja подружить?

Связку autoconf + automake почти наверняка можно. Вопрос лишь в глубине переделки последнего.

И не могу не спросить: а зачем?

а зачем?

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

Говорят, что на монстрах типа Chromium, без Ninja уже никак.

В случае с CMake использование Ninja делает сборку немного быстрее

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

Говорят, что на монстрах типа Chromium, без Ninja уже никак.

Ninja как-то по-особенному делает stat для сравнения mtime файлов чтоли? Или cmake генерирует треш вместо makefiles?

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

Речь не про время, которое компилятор тратит. Речь о самой системе сборки.

Ninja как-то по-особенному делает stat для сравнения mtime файлов чтоли?

Ninja тупее, чем make. И это хорошо, потому что инструмент сборки должен уметь делать сборку, а не быть комбайном, выполняющим лишние операции. Например, make проверяет файлы RCS и SCCS при сборке. Ты давно этими системами контроля версий пользовался? Ты ими вообще хоть раз в жизни пользовался? Зачем он их тогда проверяет?

Сейчас проверил на небольшом проекте время холостого запуска билд системы. На CMake/make это 0,7 секунд, на CMake/Ninja — 0,03 секунды. В проекте 141 файл с исходниками, не считая заголовков; половина кода — на Си, половина — на Си++.

Или cmake генерирует треш вместо makefiles?

Конечно CMake генерирует треш в Makefile's. Любая мета-система сборки будет генерировать треш, там же все зависимости прописываются. Конечно, можно Makefile руками писать, прописывая зависимости от всех заголовочных файлов, если тебе больше делать нечего. Можно использовать gcc для поиска зависимостей на лету, что замедлит холостой ребилд в разы. Зато будет не треш.

Например, make проверяет файлы RCS и SCCS при сборке

А баг никто не пробовал заводить?

Конечно CMake генерирует треш в Makefile's

Я не про «человекочитаемость» результата. Я про сложность исполнения генерируемых makefiles. К примеру, на рабочем проекте буквально из десятка файлов «холостой» запуск make дает такое распределение exec-ов:

     22 /usr/bin/cmake
     17 /bin/sh (как правило это вызовы cmake из makefile)
      6 /usr/bin/make
      3 /usr/bin/git

Связку autoconf + automake почти наверняка можно. Вопрос лишь в глубине переделки последнего.

Правильно писать "Можно, но пока нет".

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

Ninja появился во время портирования Chromium на Linux. Автор писал, что как ни пытался, не смог сократить время холостого запуска Make до значений меньше 20 с чем-то там секунд. Для этого он убрал все рекурсивные вызовы, сложив всё в один файл. Потом начал вникать в то, как работает Make, и в итоге решил попробовать сделать свой Make, но без шахмат и поэтесс. Получил время холостого запуска в пределах секунды.

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

распределение exec

Сделал аналогичные замеры.

CMake/Make:

     33 execve("/usr/bin/cmake",
     32 execve("/usr/bin/make",
     31 execve("/bin/sh",
      2 execve("/usr/bin/git",
      1 execve("/usr/bin/expr",
      1 execve("/bin/cat",

CMake/Ninja:

      2 execve("/usr/bin/git",
      2 execve("/bin/sh",
      1 execve("/usr/bin/ninja",
      1 execve("/usr/bin/expr",
      1 execve("/bin/cat",

Возможно, генератор для Ninja просто лучше написан.

Я рад, что тебя полностью устраивает Make

Скорее «по большей части».

Но ты что, пытаешься мягко намекнуть на то, что альтернативы не нужны в принципе?

Ты вроде как говоришь, что «make медленный, потому что в $PROJECTNAME холостой прогон несколько секунд занимает». Я просто вступился за несправедливо обвиненный make, поскольку доводилось заглядывать в то дерьмо, что cmake подает ему на вход.

Возможно, генератор для Ninja просто лучше написан.

Именно.

Ты вроде как говоришь, что «make медленный

Нет. Я говорил, что вариант с Ninja быстрее. Причём не только для CMake, но и для GYP, для предка которой он создавался.

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

Там что-то кардинально плохое? У CMake открытый багтрекер.

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

Вдобавок к этому Make делался для создания Makefile'ов человеком. Какой смысл в поддержке вычурного синтаксиса, если файл всё равно генерируется? В Ninja много чего нет, писать руками его почти невозможно, хотя всё ещё можно кое-как читать. Нет лишних операций.

Именно.

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

Собрать в своей системе самый свежий или наоборот староватый софт из авторских сырцов часто стало очень трудным делом.

Деградация сборщиков налицо.

Там что-то кардинально плохое?

Да. Ответственность за отслеживание изменившихся флагов компиляции/компоновки размазана между генератором (cmake) и системой сборки (make).

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

Это пишется средствами GNU make и вызовом компилятора для генерации списка зависимостей.

Вдобавок к этому Make делался для создания Makefile'ов человеком. Какой смысл в поддержке вычурного синтаксиса, если файл всё равно генерируется?

Вычурный синтаксис? Бгг, это как раз не про make.

target: dependencies
  commands

У CMake открытый багтрекер

Там должно быть всего два бага:

• cmake is defective by design
• cmake documentation is complete garbage

cmake is defective by design

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

Собрать в своей системе самый свежий или наоборот староватый софт из авторских сырцов часто стало очень трудным делом.

Деградация сборщиков налицо.

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

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