:) блин, ну не заставляй же ты меня терять веру в том, что 5 звезд таки что-то знают.

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

> прикрути к нему кодогенерацию
Какую именно? Генерировать код на С++ используя JavaScript? Сложно представляю. В моем коде вся кодогенерация держится на #define и #ifdef

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

В баше? Да ты упоролся.

А в том, что все эти мейкфайлы — фейл и профанация :}

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

жаваскрипт + jquery же!

:) ясно, 5 звезд ничего не значат. извините.

А заполнение файлов типа config.h из config.h.template это не кодогенерация? Ну и внешние тулзы к qmake'у не так удобно прикручивать. Что уж там говорить, даже lupdate и lrelease кровушки моей попили на этот счёт :) В цмаке тоже поддержку других ЯП кроме C/C++/ObjC приделывать тяжко, а иногда таки надо.

А то что можно глобально кучу таргетов сделать и потом через qbs собирать только нужные. Не нужно больше трахаться с 10ью папками сборки и каждый раз искать как правильно для неё qmake запустить (или cmake).

Вебанутость дотянулась до makefile'ов.

быстрее компилит

gcc ускоряет аппаратно?

> внешние тулзы к qmake'у
Это как раз то, о чем я не сказал в одном из первых постов.
Было бы очень приятно, если бы все настройки из .user файлов перекочевали бы в .pro/.pri файлы (а там как раз хранятся в том числе и всяческие Build steps, где можно указать запуск сторонних утилит).
После этого к qmake не было бы никаких вопросов.

Как я понял это ускоряет сборку проекта, где на 50 файлов с исходниками 48 директорий, а make выполняет Makefile'ы из разных директорий последовательно.

Ололо

С нетерпением ждём перехода KDE на новый велосипед.

> JavaScript
блджад, зачем тащить его теперь на десктопы =(

#@#@#@#@#@#@!
Да когда же они наконец-то уймутся.
ant, cmake, waf, makl, мейкфайлы с захардкоженным gcc -o appname main.c, scons...
Одна сплошная головная боль для мейнтейнеров, особенно при кросскомпайле, когда встречаешь очередное пионероподелие, котое еще и само софтину качает (makl который юзает klone, например).
Такое ощущение, что каждый не осиливший автотулзы лезет генерировать автолулзы сваоим костылем для сборки софта.

Потому, что у него есть JIT, V8 народ научился по хаутушке встраивать в приложения, вот и поперло. С node.js, на нем стало модно серверайд делать.
//Меня от JS тошнит, из скриптовых предпочитаю lua

Автолулзы не нужны!

Да-да. Все пятизвёздные должны писать кипятком от баша :]

Может тебе ещё и денег дать?

нет, всего лишь уметь программировать, если они разговаривают в топиках про программирование.

Они умеют, но баш — говно и должен умереть.

Не нужно, есть premake.

Опять же, лучше бы они это в сам qmake прикрутили.

qmake RIP. Это было известно еще в 2009-ом.

Относительно стабильности - вполне. Относительно скорости - не уверен

Lua его рвет и по стабильности, и по скорости, и по принципиальному отсутствию «темных мест» в языке.

Они умеют

после твоих сообщений, я не верю.

Это не emacs, к сожалению.

Все, кто не разделают твою религию — воры и убийцы? :3

> Это было известно
Кому?

ясно, так и запишем.

Тем кто читает их днявку: http://labs.qt.nokia.com/2009/10/12/to-make-or-not-to-make-qmake-and-beyond/

Спс за ссылку. Я тогда их еще не читал.