https://www.opennet.ru/openforum/vsluhforumID3/83043.html Разработчики из компании Nokia представили (http://labs.qt.nokia.com/2012/02/15/introducing-qbs/) новый экспериментальный сборочный инструментарий qbs (http://chaos.troll.no/~dmolkent/qbs-0.1/) (Qt Build Suite), предназначенный для сборки приложений, основываясь на данных файла-проекта, все команды которого записаны на упрощенном диалекте языка QML (http://en.wikipedia.org/wiki/QML). Файл с правилами сборки описывает только один проект, который в тоже время может содержать несколько разных программных продуктов, каждый из которых может иметь свой тип (приложение, библиотека и так далее) и отдельную схему сборки. Код qbs открыт (http://qt.gitorious.org/qt-labs/qbs) под лицензией LGPL.<br><br><br><br>Использование упрощённой версии QML для оформления файлов с правилами сборки с одной стороны упрощает интеграцию с интегрированными средами разработки, а с другой позволяет реализовать нестандартные шаги, интегрируя в файл сборки функции, реализованные на языке JavaScript, а также подключая внешние ...<br><br>URL: http://labs.qt https://www.opennet.ru/openforum/vsluhforumID3/83043.html#57 Tue, 21 Feb 2012 21:16:49 GMT &gt; Используйте Premake. Декларативный синтаксис еще более лаконичен, плюс поддержка существующих <br>&gt; IDE и независимость инструмента от Qt <br>&gt; http://industriousone.com/premake <br>&gt; http://industriousone.com/topic/full-stack-qt-based-development-premake-available- <br>&gt; download <br>&gt; http://wiki.qt-project.org/Qt_Creator/Plugins/PremakeProjectManager <br><br>замержить бы их идеи с вашими.. <br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#56 Tue, 21 Feb 2012 21:15:44 GMT &gt; освоил js и qml <br>&gt; написал программу<br><br>неа. не получается.<br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#55 Tue, 21 Feb 2012 21:14:51 GMT представь что у нас есть человек который освоил js и qml и написал программу, а тут бац за пять минут он понял как её собрать с помощью qbs.. и когда ему понадобится добавлять сложную логику он просто напишет её на явоскрипте а не на языке системы сборки.<br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#52 Fri, 17 Feb 2012 16:20:41 GMT &gt; Просчет зависимостей делает компилятор и генерерует .d файлы<br><br>это неудобно, хотя и точнее, чем можно сделать в билд-системе. и медленней, кстати.<br><br>помимо прочего, на свете есть не только два языка и один компилятор.<br><br>&gt; Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо <br>&gt; рекурсивных вызовов.<br><br>недостаточно, если я хочу, например, разные значения переменных для разных каталогов (или вообще для разных целей в одном). не то, чтобы этого совсем нельзя было сделать, но&#8230; нененене, только за большие деньги.<br><br>ну право, это бессмысленный спор: не предназначен make для ручного написания, если более-менее сложный проект собираешь. да, мэйкфайлы можно генерировать &#8212; но не проще ли тогда сделать ещё один логичный шаг и обучить генератор оставшимся функциям? ещё раз ткну пальцем в сторону jam, как весьма неплохой реализации билд-системы.<br><br>да, кстати: за табуляторы отдельный плевок. я понимаю, что &#171;нечаянно получилось&#187;, но от этого оно приятней не становится.<br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#50 Fri, 17 Feb 2012 16:08:13 GMT Просчет зависимостей делает компилятор и генерерует .d файлы, достаточно его об это попросить. Костылить ничего не надо, достаточно использовать в мейкфайлах инклуды вместо рекурсивных вызовов.<br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#48 Fri, 17 Feb 2012 15:43:00 GMT &gt; Виденная критика была местами крива сама по себе. Впрочем, обстоятельно сейчас <br>&gt; не расскажу.<br><br>ну, кое-как, с матами и воплями оно костылится.<br><br>так же, как костылится просчёт зависимостей (уж простейшие-то include система может и сама просканировать, я что, дятел &#8212; долбить ей это или костыли дёргать?).<br><br>а уж про &#171;проект &#8212; это все *.c в каталоге исходников&#187; (опять же, с просчётом зависимостей и ты пы)&#8230; не, не будем о грустном.<br><br>тот же Jam делает подобное несколькими строками. и вообще мал, реактивен (в плане скорости), удобен. для проектов среднего уровня можно его использовать и как конфигуратор заодно. да-да, я фанат jam'а, если кто ещё не заметил. и ниасилятор всего остального.<br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#47 Fri, 17 Feb 2012 15:31:21 GMT &gt; нет, я про то, что make не видит проект, раскиданый по каталогам, <br>&gt; как одно целое. уж кто только не ругался на рекурсивные вызовы <br>&gt; make в подкаталогах.<br><br>Виденная критика была местами крива сама по себе. Впрочем, обстоятельно сейчас не расскажу.<br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#45 Fri, 17 Feb 2012 15:12:04 GMT &gt; У ninja цель совершенно четкая &#8212; отделить построение DAG целей сборки и <br>&gt; их выполнение от любых &#171;конфигурационных&#187; действий, чем страдает мейк. Конфигуратор делает <br>&gt; свою работу, а нинзя &#8212; свою.<br><br>это мы уже проходили, autocrap называется. для больших проектов конфигуратор может генерить что угодно вообще, а для средних и мелких лучше иметь возможность обойтись одним инструментом. впрочем, если кто-то не может жить без конфигураторов (которые иногда больше, чем исходники всего проекта), то кто я такой, чтобы запрещать?<br> https://www.opennet.ru/openforum/vsluhforumID3/83043.html#44 Fri, 17 Feb 2012 15:09:38 GMT &gt; Интересная логическая цепочка: &#171;рекурсиный мейк не нужен&#187; &#8212; "так не используй его <br>&gt; через ж^W^W рекурсивно" &#8212; &#171;да наплевать, все равно мейк не нужен&#187;. <br><br>вообще-то &#171;make не нужен&#187; &#8212; это моя аксиома. понятно, что отсда следует, что не нужен никакой.<br>