Comments 13
А прошиватор то какой?
Актуально с учетом того, что Qt решила год назад прекратить разработку qbs.
The Qt Company announced that it will discontinue the further development of Qbs by the end of 2019 deprecated. The project is maintained by the community as part of the Qt Project.Источник
Проект переносится в разработку сообщества. Моё мнение — рано qbs закапывать.
А можете чуть подробнее рассказать как на винду поставить openocd и прикрутить его к среде разработки?
P.S. За статью спасибо :)
P.S. За статью спасибо :)
Пара вечеров ковыряния в библиотеках и qbs [ 5 ] дали положительный результат
Вот мне интересно было именно это. Я до сих пор не уловил сути qbs и как оно работает. Как написан ваш проект qbs, что там пришлось сделать и прочее? Для чего каждая строка. Вот это было бы интересно.
Ничего в теме не понимаю, но попробую объяснить, что я вижу в файле.
Сборку можно параметризовать типом cpu (переменная cpu_name). Из консоли будет как-то так (в Креаторе похожим образом):
Если ничего не передавать, то используется «E1».
Далее идут вспомогательные мапы, где ключом является вышеупомянутый cpu_name, а значениями — cpu, core и perif, соответственно. Эти мапы/переменные соответствуют конфигам в папке openocd, ключу компилятора "-mcpu" и «драйверам периферии» (чтобы это ни значило), которые лежат тут.
Дальше, собственно, заводится пачка вспомогательных переменных (по феншую они должны были быть readonly).
Затем задаётся тип нашего продукта. В qbs любой конечный результат сборки, будь то приложение, библиотека или автогенеренный файл называется Product, а различаются они типами. Именно по типу qbs понимает, что вот эту пачку cpp файлов надо собрать как библиотеку, а вот эту — как приложение. Типов у одного продукта может быть несколько, как в нашем случае — помимо сборки «приложения» мы еще собираем из него «bin» и «hex» файлы.
Дальше мы подтягиваем зависимость от модуля cpp, это модуль, который содержит правила для сборки всякого нативного стаффа (будь то c++, чистый си или objective-c). Грубо говоря, этот модуль «объясняет» qbs как из cpp файла получить конечный «application».
Дальше мы добавляем разные файлы в наш проект — это то, что мы будем собирать. Конструкции вида
Затем задаются различные флаги компилятора. Некоторые опции qbs знает сама и для этих опций выделены отдельные переменные, которые в нашем случае еще и зависят от инварианта сборки (дебаг/релиз)
А дальше начинается самое интересное — это правила сборки для файлов «bin» и «hex». Правила еще и отличаются в зависимости от дебага и релиза, в дебаге мы собираем только «bin»
Когда qbs что-то собирает, она смотрит на то, какой тип продукта мы хотим, ищет подходящее правило сборки с таким же выходным типом, смотрит, от чего это правило зависит (т.е. какой тип оно хочет на вход) и так по цепочке до тех пор, пока не найдет файл с нужным входным типом. В нашем случае цепочка примерно такая «cpp файл -> внутренняя кухня qbs -> application -> bin».
Собственно, вход правила задается переменной input, выход задается с помощью айтема Artifact (впрочем, есть также пропертя outputArtifacts), просто способ через Artifact выглядит «декларативнее».
То, как именно собирать, описывается скриптом prepare, который возвращает Command для отложенного вызова системного процесса (что-то типа future). Бывает еще JavaScriptCommand, которая вызывает кусок кода на жабаскрипте.
В общем, как-то так, если где наврал, поправьте=)
Сборку можно параметризовать типом cpu (переменная cpu_name). Из консоли будет как-то так (в Креаторе похожим образом):
qbs build project.cpu_name:E3Если ничего не передавать, то используется «E1».
Далее идут вспомогательные мапы, где ключом является вышеупомянутый cpu_name, а значениями — cpu, core и perif, соответственно. Эти мапы/переменные соответствуют конфигам в папке openocd, ключу компилятора "-mcpu" и «драйверам периферии» (чтобы это ни значило), которые лежат тут.
Дальше, собственно, заводится пачка вспомогательных переменных (по феншую они должны были быть readonly).
Затем задаётся тип нашего продукта. В qbs любой конечный результат сборки, будь то приложение, библиотека или автогенеренный файл называется Product, а различаются они типами. Именно по типу qbs понимает, что вот эту пачку cpp файлов надо собрать как библиотеку, а вот эту — как приложение. Типов у одного продукта может быть несколько, как в нашем случае — помимо сборки «приложения» мы еще собираем из него «bin» и «hex» файлы.
Дальше мы подтягиваем зависимость от модуля cpp, это модуль, который содержит правила для сборки всякого нативного стаффа (будь то c++, чистый си или objective-c). Грубо говоря, этот модуль «объясняет» qbs как из cpp файла получить конечный «application».
Дальше мы добавляем разные файлы в наш проект — это то, что мы будем собирать. Конструкции вида
app_path + "/**/*", по сути, включают все файлы в папке app_path. Так обычно не делают, а перечисляют каждый файл явно, но так как это шаблон, то можно и так. Само по себе добавление ничего не делает, просто qbs теперь знает, что наш продукт зависит от только этих файлов.Затем задаются различные флаги компилятора. Некоторые опции qbs знает сама и для этих опций выделены отдельные переменные, которые в нашем случае еще и зависят от инварианта сборки (дебаг/релиз)
А дальше начинается самое интересное — это правила сборки для файлов «bin» и «hex». Правила еще и отличаются в зависимости от дебага и релиза, в дебаге мы собираем только «bin»
Когда qbs что-то собирает, она смотрит на то, какой тип продукта мы хотим, ищет подходящее правило сборки с таким же выходным типом, смотрит, от чего это правило зависит (т.е. какой тип оно хочет на вход) и так по цепочке до тех пор, пока не найдет файл с нужным входным типом. В нашем случае цепочка примерно такая «cpp файл -> внутренняя кухня qbs -> application -> bin».
Собственно, вход правила задается переменной input, выход задается с помощью айтема Artifact (впрочем, есть также пропертя outputArtifacts), просто способ через Artifact выглядит «декларативнее».
То, как именно собирать, описывается скриптом prepare, который возвращает Command для отложенного вызова системного процесса (что-то типа future). Бывает еще JavaScriptCommand, которая вызывает кусок кода на жабаскрипте.
В общем, как-то так, если где наврал, поправьте=)
Sign up to leave a comment.
QBS шаблон для программирования микроконтроллеров в QtCreator на примере контроллеров Миландр