Про DVI кстати не уверен, надо почитать

Ага, не туда посмотрел, и правда.

Так он давно показал, что не шарит. А что тогда? Неужели гредл?

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

Да, гредл.

Эм, нет. Просто нет. У мейка есть киллер-фича - простота интеграции с любым компилятором. Даже с несколькими, если хочется. Гредл с даже парочкой плагинов - дорога в жёлтый дом. Зачем мне несколько компиляторов - чтобы быть уверенным, что код в статье работает.

Единственный минус - для винды надо писать с нуля.

Что можно обойти с мингв, конечно, но не рекомендуется.

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

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

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

> что, кстати, всё равно ломает инкрементальную компиляцию, потому что граф зависимостей с циклами и весь цикл надо перекомпилировать.
Весь цикл, но не вообще ж всё целиком. Потому я б не сказал, что прям ломает.

> Короче, если что-то нельзя сделать на мейке, но можно в другой системе сборки - это ооочень странно, потому что DAG - он везде DAG, только в мейке его надо ручками писать.
Но в других системах DAG может быть более гранулярен. Хотя я и не уверен, что я такое видел в продакшн-грейд тулзах.

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

> но не вообще ж всё целиком

Компилятор всё равно компилирует файлами.

> фантазии

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

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

Чёт не находится ничего. @angmarr, ты у нас тут главный по всяким интересным, но далёким от прода идеям. У тебя нет ничего под рукой о менеджменте зависимостей, где зависимостями бы были не целые библиотеки, а отдельные функции? И соответственно любое изменение в функцию давало бы новый хеш. Мне казалось, что я читал об этом у Тонского, но либо меня подводит поиск, либо память.

Вы говорите не про то. Зависимости между файлами и прочее - это чудесно, но все это рассчитано на glue code, когда все, что вам нужно уже есть в консольке. А что делать когда нет? Шаблоны в техе? Деплой на сервер? Трансформации строк? На чем это писать, на баше?

Шаблоны в техе — это что?
Деплой на сервер — курл, к примеру.
Трансформации строк — это что?

Опять же, я вам мейк не продаю, делайте, что хотите и как хотите. Я лишь говорю об альтернативе.

Шаблоны - это то, с чего началось текстовый шаблонизатор. Курл - это внешняя зависимость, которую ещё установить надо (и не говорите мне, что он всегда есть, я тут какое-то время назад бился над тем, чтобы поднять его версию в центосе).

Ну и ответ скорее не вам, а вообще в тему.

Собственно js