Qt Build System: спасательный круг для сборки


    Примечание(17.06.2013): синтаксис примеров в статье не соответствует последним версиям. Сверяйтесь с документацией. Также в марте был выпущен Qt Creator 2.7 с поддержкой QBS.
    Не так давно команда разработчиков Qt представила новую систему сборки — QBS. Разумеется, основной реакцией было «Да чем вас QMAKE не устраивал», «Просто адаптируйте CMAKE», «Ещё одна система сборки [xkcd, стандарты]». Обещанные преимущества новой системы: гибкость, понятный синтаксис для всех разработчиков (QML — javascript-подобный декларативный язык), скорость билдов (чистых и инкрементальных), а также лёгкая расширяемость.
    Всё это мы где-то уже слышали, поэтому в данной статье мы попытаемся разобраться, как разработчики пришли к этой системе, рассмотрим простейшие примеры, изучим основные конструкции и посмотрим, какая поддержка на уровне IDE присутствует на настоящий момент.

    История


    Сейчас мы вместе постараемся повторить путь Йорга Борнемана (Jörg Bornemann), разработчика QBS.

    Критика make (и производных)

    В статье Peter Miller 1999 года рассматривается проблематика рекурсивного make и вообще удобства makefile'ов как таковых.
    • Традиционная для UNIX система сборки make выдает непозволительно долгое время сборки для больших проектов (особенно для инкрементальных сборок);
    • Использование рекурсивого вызова make из корневой директории приводит к нарушениям зависимостей между модулями, для устранения которого приходится запускать сборку два или три раза (и увеличение времени сборки, естественно);
    • Использование единого makefile устраняет недостатки, но поддержка становится невыносимой. О какой-либо достаточной поддержки изменений makefile с помощью IDE речи не идёт.


    В статье Adrian Neagu 2005 года рассматриваются более общие проблемы make:
    • Портируемость make сильно раздута, так как make работает не сам по себе, в makefile могут быть указаны десятки других утилит, которые специфичны для платформы;
    • Масштабируемость ужасна, при использовании рекурсивного make (то же мнение, что в предыдущей статье), и недостаточна при использовании include или других расширений. В частности, производительность сборки падает очень быстро.


    В статье «Что не так с GNU Make»
    Более подробно расписаны минусы языка и те же самые проблемы что и ранее (не буду повторяться)
    • Неочевидные и откровенно ущербные элементы языка (чего стоят только ifeq, ifneq, ifdef, и ifndef)
    • Проблемы типов (работа только со строками)
    • Плохое разрешение зависимостей в случае изменения опций командной строки
    • Проблемы с одновременным запуском и распараллеливанием
    • Легко «убить» дерево сборки внезапной остановкой программы.
    • И много других мелких косяков, которые свидетельствуют о неподходящей архитектуре под современные нужды (по мнению автора).


    В короткой заметке Ian Lance Taylor, 2007 г. рассмотрен основной недостаток Cmake как замены Make — Он. Слишком. Сложен. Это адская смесь нескольких языков, поддерживать её (для действительно сложных систем) могут только гуру разработки и отладки (отлаживать её тоже проблематично). Ещё одним недостатком является то, что за гибкость (даже ГИБКОСТЬ), приходится расплачиваться потерей производительность в сгенерированных скриптах.

    Что не так с QMake?

    В инфраструктуре Qt на сегодняшний день широко используется система сборки Qmake, которая поддерживается официально и все ещё дорабатывается. Зачем же возникла надобность «just another one» системы сборки?

    В статье Marius Storm-Olsen анализирует следующие недостатки qmake:
    • Свой, самобытный синтаксис языка.

      Попробуйте посмотреть на QTDIR/mkspecs/features/exclusive_builds.prf:
      DEFINES += QT_NO_CAST_TO_ASCII
      !macx:DEFINES += QT_USE_FAST_OPERATOR_PLUS QT_USE_FAST_CONCATENATION
      
      unix {
          CONFIG(debug, debug|release):OBJECTS_DIR = $${OUT_PWD}/.obj/debug-shared
          CONFIG(release, debug|release):OBJECTS_DIR = $${OUT_PWD}/.obj/release-shared
          CONFIG(debug, debug|release):MOC_DIR = $${OUT_PWD}/.moc/debug-shared
          CONFIG(release, debug|release):MOC_DIR = $${OUT_PWD}/.moc/release-shared
          RCC_DIR = $${OUT_PWD}/.rcc
          UI_DIR = $${OUT_PWD}/.uic
      }
      


      Понять такое сразу, даже «поллитры» не хватит. Хотя с этим еще CMake может потягаться.
      Пусть программист знает С++, Pascal, Javascript, win&unix shell и SQL — все эти знания окажутся бесполезными в освоении системы сборки.
      От себя могу добавить, что много хлопот мне доставил символ "#" в путях и возня с $$LITERAL_HASH (зачем придумывать способ экранирования спецсимволов языка? Введём свои макросы лучше).
    • Поддержка IDE.
      Qt creator поддерживает добавление новых файлов в проект, но стоит чуть отойти от «привычного» ему синтаксиса, он просто может добавить в конец новую констркцию HEADERS или FILES.
    • Отсутствие сборки как таковой в qmake.
      Qmake не собирает ваш проект. Название обманчиво. Он лишь генерирует Makefile, а сборку осуществляет одна из утилит Make (*nix — gnu make, win- nmake, jom или mingw-make).
    • Отсутствие прозрачной поддержки кросс-компиляции, сборки пакетов и деплоймента.

    Наконец, мы подошли к тому моменту, как в рассылке Qt обсуждалась новая система сборки и требования для неё:
    • Она должна быть ОЧЕНЬ быстрой (незаметное время чтобы произвести stat() всех файлов);
      Изменение узла где-то в глубине дерева сборки не должно приводить к изменению конфигурации всего дерева;
    • У неё должен быть простой и понятный язык, который может быть легко понят людьми и обслужен скриптами;
      Язык должен быть хорошо специализирован;
      Он должен быть декларативным в своей структуре, с небольшими императивными фрагментами, жёстко изолированными от остальных;
      Язык должен основываться на свойствах, а не на командах. Никаких CFLAGS. (cmake на полпути к этому);
    • Должна быть полная поддержка модульности. Также любой подпроект должен иметь возможность легко отделяться от родительского (и присоединяться к другому). Т. е., грубо говоря, взяли папку с конфигурацией сборки, вставили в другой проект -там тоже все хорошо собирается (без учёта зависимостей конечно);
    • Чёткая и ясная поддержка для IDE;
    • Должная быть возможность сборки разных конфигураций под разные платформы в один проход.


    Представляем «спасательный круг» — Qt Build System


    15 февраля 2012 года в Qt labs Йорг Борнеман представил общественности проект QBS. Сейчас он находится даже не в состоянии альфы, а где-то посередине между прототипом и альфа-версией. В оправдание можно сказать, что Qt Creator уже собирается с её помощью.
    Основные принципы проектирования новой системы:
    • Декларативность — используется QML синтаксис;
    • Расширяемость — есть возможность писать свои модули для сборки, либо кодогенераторы и т. п. (ниже мы попробуем написать свой модуль для сборки проектов Delphi);
    • Скорость;
    • Сборка напрямую — это не qmake, это не «посредник». Qbs сама вызывает компиляторы, компоновщик, и что там еще понадобится.

    Чего пока нет: проверки конфигурации системы(используется запрос к qmake для конфигурирования тулчейнов), сборки пакетов, деплоймента, запуска тестов и самое главное — поддержки каких-либо ide, кроме особой ветки QtCreator-а.

    Начнём пробовать!

    Автор советует собрать qbs из исходников, но можно иметь ввиду, для пользователей win и linux есть бинарные сборки
    win — собрано под MSVC2010. Я бы тоже посоветовал собрать версию из git ( у меня проблемы были с плагинами и MOC).
    В бинарном виде qbs зависит от библиотек QtCore и QtScript (+Concurrent для Qt5)
    Создадим Hello World проект на С++:
    main.cpp
    #include <iostream>
    using namespace std;
    int main()
    {
    	cout << "Hello world!" << endl;
    	return 0;
    }
    


    Создадим также минимальный проект на qbs:
    hello.qbp
    import qbs.base 1.0
    CppApplication {
         name: "HelloWorld"
         files: "main.cpp"
    }
    

    LINUX:
    1. Открываем в текущей папке шелл.
    2. Добавляем путь, куда вы распаковали/собрали qbs, в PATH (вернее, bin папку)
    PATH=~/qbs/bin/:$PATH
    3. запускам qbs:
    qbs
    Found project file /home/mapron/статья/example-3/hello.qbp
    loading project took:  69 ms 
    build graph took:  18 ms 
    for debug:
      - [hpp, application] HelloWorld as debug
    
    compiling main.cpp
    linking HelloWorld
    Build done.
    

    После этого программа сборки запустит разбор проекта и соберет в папке build/debug исполняемый файл (ну мы же не указали пока папку назначения?)
    WINDOWS:
    4. Поскольку под Windows, как правило компилятор и qt не находятся в PATH, qbs может попросить вас запустить «qbs platform probe», что необходимо сделать.
    5. затем возможно, понадобится запустить qbs config update или подобное (если он попросит, возможно это исправили уже).
    6. после этого при запуске qbs [build] — вы получите собранный бинарник «HelloWorld.exe»

    Продолжаем изучать

    Теперь попробуем освоить сборку чего-то более сложного, и заодно, разобраться с языком.
    Для начала, создадим новую папку и скопируем туда папки «2dpainting» и «collidingmice» из папки examples с Qt.
    Почему сразу два? Мы создадим конфигурацию для сборки сразу двух продуктов.
    Продукт — это целевой «выход» системы сборки, подобие «.pro» файла при сборке Qmake. В одном проекте qbs может быть несколько продуктов.
    Для начала создадим проект «examples.qbp»

    //Подключаем стандартные библиотеки в стиле QML
    import qbs.base 1.0 
    import qbs.fileinfo 1.0 as FileInfo
    Project {   // основной элемент файла - проект. 
        moduleSearchPaths: "qbs" // Папка для поиска дополнительных модулей, таких как cpp и qt
        // Один проект может состоять из нескольких продуктов - конечных целей сборки.
        Product {
            name: "2dpainting"       // Название выходного файла (без суффикса, он зависит от цели)
            type: "application"     // Тип - приложение, т.е. исполняемый файл.
            Depends { name: "cpp" } // этот продукт зависит от компилятора C++
            Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] }   // И Qt модулей QtCore, QtGui, QtOpengl
            files: [ // список файлов в данном проекте. пока они в поддиректории, организуем позже.
                "2dpainting/glwidget.h",
                "2dpainting/helper.h",
                "2dpainting/widget.h",
                "2dpainting/window.h",
                "2dpainting/glwidget.cpp",
                "2dpainting/helper.cpp",
                "2dpainting/main.cpp",
                "2dpainting/widget.cpp",
                "2dpainting/window.cpp",
            ]
        }
    }
    


    Откроем консоль и попробуем собрать, выведется ошибка «ERROR: Error while setting up build environment: qt.core.incPath not set. Set qt.core.incPath or qt.core.path in your profile. »
    Закроем пока глаза на не слишком юзер-френдли способ конфигурации, и создадим файл «qbs.config» с таким содержимым (WINDOWS):
    modules.qbs.platform: MSVC2010
    profile: default
    profiles.default.qt.core.path: C:/QtSDK/Desktop/Qt/4.8.1/msvc2010/
    


    либо под LINUX (ubuntu):
    modules.qbs.platform: gcc
    profile: default
    profiles.default.qt.core.binPath: /usr/bin/
    profiles.default.qt.core.libPath: /usr/lib/qt4
    profiles.default.qt.core.incPath: /usr/include/qt4 
    profiles.default.qt.core.mkspecsPath: /usr/share/qt4/mkspecs
    

    и запустить qbs config --import qbs.config
    После этого qbs нормально сможет собрать проект и поместит выходной файл в папку build/debug.
    Для того чтобы собрать проект в релиз, выполните «qbs build release».
    Для очистки всех файлов сборки (т. е. Папки «build») выполните «qbs clean».
    Теперь попробуем организовать расширяемую структуру для двух проектов. Создадим в подкаталогах «2dpainting» и «collidingmice» файлы-тёзки своих каталогов с расширением «.qbs» с таким содержимым:

    import qbs.base 1.0 
    Product {
        name: "2dpainting"
        type: "application"
        Depends { name: "cpp" }
        Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] }
        files: [ // чтоб не раздувать по вертикали, напишу в две колонки.
            "glwidget.h",     "helper.h",
            "widget.h",       "window.h",
            "glwidget.cpp",   "helper.cpp",
            "main.cpp",       "widget.cpp",
            "window.cpp",
        ]
    }
    


    import qbs.base 1.0 
    Product {
            name: "collidingmice"
            type: "application"
            Depends { name: "cpp" }
            Depends { name: "Qt"; submodules: ["core", "gui", "opengl"] }
            files: [ "mouse.h","main.cpp", "mouse.cpp" ,"mice.qrc"]
        }
    


    Т.е. мы разбиваем код на независимые продукты, которые могут собираться параллельно. Внесём изменения в examples.qbp:
    //Подключаем стандартные библиотеки в стиле QML
    import qbs.base 1.0 
    import qbs.fileinfo 1.0 as FileInfo
    Project {   // основной элемент файла - проект. 
        moduleSearchPaths: "qbs"
        // Один проект может состоять из нескольких продуктов - конечных целей сборки.
        // указываем связанные файлы с помощью references. Внимание: это не жестко заданный порядок!
        // Порядок задается с помощью зависимостей, о них позже
        references: [
               "2dpainting/2dpainting.qbs",
               "collidingmice/collidingmice.qbs",
           ]
    }
    


    Можете снова запустить «qbs». Обратите внимание, для «.qrc» файла будет автоматически вызван «rcc» и все это слинковано вместе. Все файлы при этом указываются одним списком, без разделения на HEADERS, SOURCES и т. д., как было в qmake.

    Как это все работает?

    Для начала рекомендую бегло ознакомиться со справкой
    Основные концепции языка: Проект (Project), Продукт (Product), Артефакт (Artifact), Модуль (Module), Правило (Rule), Группа(Group), Зависимость (Depends), Тег (Tag).
    Продукт — это аналог pro или vcproj, т. е. одна цель для сборки.
    Проект — это набор ваших продуктов вместе с зависимостями, воспринимаемый системой сборки как одно целое. Один проект — один граф сборки.
    Тег — система классификации файлов. Например «*.cpp» => «cpp»
    Правило — Преобразование файлов проекта, отмеченных определенными тегами. Генерирует другие файлы, называемые Артефактами. Как правило, это компиляторы или другие системы сборки.
    Артефакт — файл, над который является выходным для правила (и возможно, входным для други правил). Это обычно «obj», «exe» файлы.
    У многих QML-объектов есть свойство condition, которое отвечает за то, будет собираться он или нет. А если нам необходимо разделить так файлы? Для этого их можно объединить в группу (Group)
    Group { 
                condition: qbs.targetOS == "windows" 
                files: [ "file1", ...]
    }
    

    примерно таким образом.

    Что же дальше?


    Закономерный вопрос, примеры это здорово, а как можно отправиться в свободное плавание с этой системой? Можно:
    • Читать документацию;
    • Скачать исходники Qt Creator и посмотреть как QBS используется там;
    • Изучать исходники самого QBS (на крайний случай).


    Заключение


    QBS предоставляет нам следующие плюсы:
    • Удобный и понятный формат конфигов сборки
    • Высокую скорость
    • Чёткую модульную архитектуру

    Но, к сожалению имеет следующие (временные минусы)
    • Наличие большого количества багов (это ещё не альфа);
    • Отсутствие поддержки IDE (ждем в Qt Creator);
    • Отсутствие системы сборки пакетов, инсталляторов (в планах).


    К сожалению, формат статьи не позволяет раскрыть все тонкости, в дальнейших планах раскрыть тему:
    1. Создание собственного модуля (он включён в архив с примерами);
    2. Написание правил для сборки;
    3. Создание js-модулей и их включение;
    4. Создание своих типов продуктов;
    5. Работа с глобальным конфигом и конфиги модулей;
    6. Написание своего плагина (для парсинга зависимостей .drpoj файла).

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

    Ссылка на архив со всеми примерами к статье:
    narod.ru/disk/49759080001.18d6748f8ef86e26c6dea2e2c5ed7d13/examples.zip.html
    В архиве БОНУС! не упомянутый в статье пример модуля для сборки DELPHI 2007 проекта (планируется сделать разбор в следующей статье).

    Ссылки


    labs.qt.nokia.com/2012/02/15/introducing-qbs — представление
    doc-snapshot.qt-project.org/qbs — документация
    qt.gitorious.org/qt-labs/qbs — git
    bugreports.qt-project.org/browse/QBS — багтрекер.

    Примечание: Qt Build Salvation (Спасение для сборки Qt) — внутреннее имя QBS, в README дерева исходников.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 49
      +2
      Интересная вещь, особенно учитывая подключаемые модули. Раньше в этом плане мне нравился малоизвестный bam, но теперь хочется попробовать QBS :-)
        +3
        Штука действительно занимательная. Вот сейчас только закончил разбираться с написанием плагинов и ковырянием кода для поддержки сканирования по маске, надо будет рассказать потом)
        +1
        Вот почему всегда в качестве примера приводится сборка какого нибудь «Hello World» (не только для данной системы справедливо, для make, cmake тоже самое)? Нет чтобы взять проэктик с парой модулей там, с более ли менее сложной организацией, детально показать какие преимущества дает для крупных проектов.
          0
          Пока главное преимущество — скорость. По сравнению с nmake — более чем в два раза. Какая принципиально разница будет если я вместо сборки 2х приложений вставлю 10?
          А вот насчет более сложных либ, с наследованием и прочими вкусностями согласен. Просто не стал раздувать статью для первой публикации.
            +1
            Если хочется монструозный примерище, я дал ссылку — исходники Qt Creator. Там куча qbs модулей, со сложными скриптами. Работает. Я с их помощью и разбирался в хитросплетениях.
            0
            Ух наконец кто-то решился одолеть эту проблему. Я уж боялся, что придется ковыряться и изучать синтаксис всех этих make/cmake/qmake (так как под nix* ничего серьезного не пишу, но иногда бывает необходимо).
              0
              Пока QBS не выйдет на стадию альфы хотя бы, вам все равно придется изучать синтаксис «всех этих». Ну и тем более библиотеки вроде буста вряд ли на него перейдут даже в отдалённом будущем.
                0
                А кто их знает. На самом деле зависимостей у QBS совсем чуть чуть, они сами сказали, что будут приветствовать сторонние проекты, это будет не как вещь в себе типа qmake.
              +3
              Великолепно, что любимая библиотека развивается в разных направлениях!
                +4
                Выглядит просто офигительно. Такой простой синтаксис — просто сказка какая-то.
                  +3
                  Ох, жду не дождусь когда он зарелизится… Прямо мечта!
                  А за статью спасибо =)
                    +3
                    Пожалуйста, приятно получить одобрение, буду писать ещё, о продвинутом использовании!
                      +2
                      Вот интересно было бы не просто «продвинутое использование», а в сравнении с qmake: создать .pro и .qbs файлы для сборки одного и того же сложного проекта, чтоб наглядно продемонстрировать преимущества новой системы.
                        +1
                        Хм, не думал о таком, спасибо за идею. Принимаю. А пока можете сравнить pro и qbs файлы в исходниках QtCreator, как я уже упоминал. На мой взгляд, ЧИТАЕМЕЕ на порядок.
                          +1
                          Кстати, вот сравнение, возможно вас заинтересует:
                          qt-project.org/wiki/Qbs_Quick_Reference
                      +2
                      Молодцы! Надеюсь что эта технология станет общепринятой.
                      От make-файлов давно пора отказаться… иногда приходится сталкиваться с программированием под Linux, не понимаю как такая дикая смесь какого-то древнего бейсика и не менее древнего командного процессора могла так долго просуществовать.
                        +2
                        Очевидно же, «работает — не трогай». Других причин просто не вижу. :}
                          +1
                          Дело, скорее, в совместимости.
                            +1
                            Хм, точно. Совсем забыл.
                            «Жертвуйте производительностью ради совместимости», или как-то так. На память пишу, и не помню где читал. Что-то вроде юникс-вея? Кто напомнит.
                            +1
                            Согласен, здоровый консерватизм и инертность в таких фундаментальных вещах, как система сборки, иногда не лишние.
                            Но и мучаться от ущербного дизайна тоже вечно нельзя. Надо переходить… и qbs предлагает отнюдь не эволюционный метод.
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • НЛО прилетело и опубликовало эту надпись здесь
                                +2
                                qbs именно так и сделан. Он не привязан ни к чему. Можно свои парсеры для поддержки pas файлов сделать к примеру.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +4
                                      В QBS парсер на си пишется для поиска зависимостей файлов, например для *.c, *.cpp, *.mm файлов ищутся #include директивы, по которым становится понятно от каких header'ов он зависит, чтобы в нужный момент послать его на пересборку
                                      Вся остальная логика (какие указать флаги для компилятора, линковщика и т.п.) реализована уже в QBS модулях (в qml стиле)
                                        +4
                                        Спасибо, хоть кто-то в теме. Кстати, могу добавить что в правила для сборки можно написать свой небольшой парсер текстовых файлов (например, для кодогенерации), для небольших проверок на JavaScript. Например для автоматической замены версий или копирайтов.
                                          +1
                                          Да, это возможно) Довольно занятная штука
                                          К слову, игрался с QBS пару месяцев назад, пофиксил там ряд багов, но обломился из-за одного момента — QBS тогда не умел подхватывать в качестве инклудов сгенерированные хидеры из другого продукта, не подскажешь — это уже пофиксили или нет? (На тот момент собирались делать что-то странное с этим, но я так и не понял по рассылке — что именно)
                                            +1
                                            ну я прикрутил dumcpp он генерирует h и cpp. Работает вроде. Может я конкретную вашу цель не понял.
                                              +1
                                              Если быть конкретнее:
                                              а) есть библиотека libboo, она генерирует version.h;
                                              б) есть приложение foo, среди его артефактов есть goo.cpp, который содержит #include <boo/version.h>.
                                              Вопрос — как их подружить? Если:
                                              а) на момент скана version.h еще не существует;
                                              б) поиск хидеров идет только среди глобальных мест (типа /usr/include) и артефактов данного продукта. (Построитель графа зависимостей даже не пытается искать version.h среди артефактов проекта libboo).
                                              В итоге возможна ситуация, когда goo.o будет пытаться скомпилировать до того, как сгенерируется version.h
                                                +1
                                                Depends для этого сделали. И нужно version.h добавить в список файлов проекта. Тогда ок будет. у меня похожая фигня была) вроде работает, но я наматюгался пока все настроил)
                                                  +1
                                                  Не подскажешь как именно? Просто это единственное, что мне помешало сборку кутима до конца на qbs перевести (за исключением поиска внешних зависимостей, но это легче довести до ума)
                              +3
                              Отлично, спасибо.

                              Такой вот вопрос хочу задать, я смотрю все свойства задаются строками.
                              Т.е. не используются какие-либо перечисления допустимых типов, а именно строки:
                              «cpp», «application» и т. д.

                              А как система отреагирует на некорректное значение, опечатку и т. д?
                                +1
                                в случае с типом сборки — проигнорирует, если у вас не настроены специальные цели. application, «staticlibrary» — это не зашитые типы, они настраиваются в модулях.
                                cpp — скажет что нет такого свойства (модуля).
                                Свойства не обязательно строками — можно любые допустимые в JS. главное чтобы модуль это обработал.
                                я могу property variant foo: 'blah'; задать и обрабатывать его либо как строку либо как массив.
                                Можно объекты и тп. (в общем, смотрим доки по QML)
                                +1
                                Почему-то еще все забывают такую важную вещь в сборке, как конфигурирование… например, как настроить include/lib paths для 3rd party библиотек. Конечно, если по старинке делать как в make, т.е. писать/генерить через configure.sh, но уже не 1999 год. Такие вещи должны включаться в систему сборки, как must have.
                                  +1
                                  Для этого и разработана система модулей. В модуль включается процедура конфигурирования.
                                  Сейчас правда проще через глобальный конфиг все фигачать, нестабильный механизм какой-то =(, но в архитектуре все предусмотрено уже!
                                    +1
                                    И кроме конфигурирования, в дизайне предусмотрена процедура для сборки пакетов и деплоя. Тоже будет в модулях. Просто пока нет реализации.
                                    +1
                                    Долгих лет!
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        +2
                                        как я уже писал, мне удалось модуль сборки для DELPHI 2007 написать. при этом без правки исходников.
                                        для поддержки парсинга зависимостей правда пришлось еще плагин написать.
                                        Еще довольно просто пишется модуль для кодогенератора dumpcpp.
                                        Т.е. в теории — может всё собирать.
                                          +1
                                          Не поделитесь парсером? Интересно было бы попробовать.
                                          +2
                                          из «коробки» уже сейчас:
                                          -С/с++, .h файлы
                                          -генерация и сборка moc (автоматом)
                                          -qrc файлы
                                          -rc файлы для msvc
                                          -генерация pch, внедрение манифестов для msvc
                                          -почти полная поддержка всех qt модулей.
                                          +3
                                          Вроде слышал, что там еще можно делать нечто вроде фильтров чтобы осуществлять генерацию проектных файлов. Правда в комментах эту фичу как теоретически возможную описывали, но говорили, что если очень хочется, то можно написать генератор студийных проектов.
                                            +1
                                            Судя по всему, проект заглох. Никаких серьёзных изменений за последние два месяца в проекте не было… в основном правки наподобие оптимизаций и чистки кода.
                                            Все еще смотрю на проект с надеждой, но она тает с каждым днем. Пока продолжаю использовать те же сборочные скрипты (удобно и не нужно дополнительно ничего делать), своей модифицированной версии qbs (с возможностью сканирования директорий).
                                            P.S. В переписке Йорг и Освальд… довольно агрессивно что ли, отнеслись к предложению каких-либо новшеств. Мне показалось слишком уж консервативно для такого молодого проекта, поэтому я плюнул на попытки ваять патчи для них. Может и зря.
                                              0
                                              Добавились Probe'ы для возможности поиска библиотек, добавились wildcard'ы, мы сумели им собрать qutIM со всеми зависимостями. Нормально они к патчам относятся.
                                                0
                                                Joerg и Oswald, так же как и другие разработчики Qt очень положительно относятся к патчам. Просто они должны быть оформлены в соответствии с правилами и соответствовать Qt Coding Style Convention.
                                                  0
                                                  хорошо, я неправ. Просто значит качество кода которое я предоставляю проекту, не соответствует высокому стандарту.
                                                    0
                                                    Просто не нужно бросать патч на полпути, а исправлять указанные недочеты.
                                                +1
                                                По ссылке «сильно сложным» считают не cmake, а… autotools. Про сам же cmake сказано только то, что он требует установки доп. пакета, что правда и в случае с qbs.
                                                Ну и опять же несправедливо забыта ninja, у которой нет поддержки IDE, но которая тоже очень быстра.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое