All streams
Search
Write a publication
Pull to refresh
12
0
Send message
> На уровне кода Qt 6, полагаю, сможет работать и на Win2k

Наврятли, т.к. там изменения не только связанные с отрисовкой. Начиная с версии 5.7 (если не ошибаюсь), минимальная версия Windows это 5.7. Там изменения, как минимум коснулись с работой с сетью, там используется теперь Win API из Windows 7 (которых нету в XP и ниже). Может и еще где что-то «обновили», не знаю… Я бы не надеялся на все что ниже 7-ки ))
Добавил в маркет версию 0.0.8. Теперь можно установить по-нормальному. Используйте на здоровье, товарищи! ))
> Посмотрите в сторону qbs, тоже декларативный синтаксис, но более однородная среда и не прибита гвоздями к С++

Неистово плюсую этого господина, тем более, что уже готовится к релизу плагин для VSCode.
Ага, и до сих пор они домучать этот CMake не могут.
Это уже не ку-тешники, а комьюнити. И развивается даже быстрее чем было при ку-тешниках.

Кроме того комьюнити для Qbs пилит плагин для VSCode: github.com/denis-shienkov/vscode-qbs

Скоро анонс на хабр постараюсь добавить (плагин в принципе уже готов). ;)
Ах, ясно. Я почему-то думал, что clang-овский парсер более гибкий, что ему можно как-то подсунуть список ключевых слов и прочее, без указания триплетов… Но, видать — не судьба.
> xtensa не поддерживается LLVM/CLang, как результат парсинг и модель ломается в QtC

Да, у QtC шного парсера (что clang, что дефолтного) проблемы с парсингом кода для специфичных архитектур. Например, если имеются какие-нибудь особенные ключевые слова (например, для 8051 такие как 'data', 'xdata', 'sfr' и прочие), которых парсер не знает.

Я даже баг-трекер создавал с предложением расширить парсеры так, чтобы можно было из любых плагинов QtC дополнять словарь ключевых слов для текущего выбранного тулчейна (хотя-бы для встроенного не-clang парсера). Например, если используем тулчейн от Keil и архитектура 8051 — то «подключаем» ключевые слова именно для этой архитектуры и этого тулчейна и т.д. Но что-то никто не хочет с этим связываться.

Но а по поводу xtensa я что-то не понял в чем там проблема? Ведь там используется обычный GCC. Правда, я использую с xtensa (esp8266) всегда встроенный парсер вместо clang-овского, т.к. он менее глючный.
Доброго дня.

Да, конечно, можно и GCC — оно идет по-умолчанию, и уже сто лет как поддерживается.

Просто если хочется отладки с GCC, то нужно выбирать «поставщиков» отладки типа GDB (например, OpenOCD, StLink Utility и прочее).

А вот если хочется отладки с Keil — то «поставщиков» отладки типа UVSC (тех, что имеют префиксы uVision).

А вот чтобы миксовать их, например для GCC использовать поставщик от uVision — я не пробовал. Хотя обратное работает — когда мы отлаживаем код, скомпиленный компилятором от Keil-а в GDB.
> но тулчейн/исходники ядра/инструкцию по сборке rootfs от вендора получить не удалось.

Я как бы в таком случае много раз собирал Qt как то так (так, сказать, по-быстрому):

1. Берется и «сливается» rootfs из реального у-ва посредством rsync (или иным образом).
2. Берется любой готовый тулчейн (GCC) для ARM примерно той-же версии что и использовался на у-ве (просто ставим из репозитория на хост или качаем отдельно).
3. На хосте запускаем 'qemu-static-arm' (или как оно называется), чрутимся на скачанную rootfs и доустанавливаем 'devel' пакеты в rootfs (те, которые нужны для сборки, если, конечно, у железки есть свой репозиторий). Если репозитория нет — то придется собирать все недостающие пакеты кросс-компилятором и «устанавливать» в rootfs.
4. Собственно, всё, кросс-компилим Qt используя наш тулчейн и «нашу» rootfs.

PS: И да, как уже сказали выше — это самый быстрый и простой способ.

Благодаря декларативному синтаксису, работать с этой системой сборки одно удовольствие, проекты получаются простыми и достигается максимальное переиспользование кода.


Что правда — то правда.

Постоянно в проектах предпочитал и предпочитаю использовать Qbs && QtC. Это гораздо проще и быстрее чем CMake (но это мое ИМХО, а так, конечно, всЁ на любителя).

я конечно извиняюсь, но...


Ну вот, опять… Не надоело еще? Везде где в темах упоминается о Qbs появляются такие личности, которые готовы что-то да вбросить… Прошло уже 2 года, а поток этих «вбросов» всё не уменьшается.
Я не пробовал, т.к. не имею его в наличии.
Да, работает. Но я не собирал, я качал готовые сборки, например, последняя доступная v1.3.0.
Не рекламы ради, но в QtCreator это все делается быстрее и проще. ;)
Да, бывает(бывало) иногда. Но, может быть, это зависит от GDB провайдера. Например, последнее время я использую ST-Util, вместо OpenOCD. Вроде пока все более-менее стабильно было.

PS: Хотя, я не ковырял сам движок отладчика GDB, т.к. его «пилят» ребята из Qt-company. Попробуйте создать баг-репорт, может поможет. :)
Есть люди, заинтересованные в продолжении развития QBS. Тот факт, что от него отказались Qt-шники ничего не меняет. Есть очень хорошая (но маленькая) команда которая продолжает развитие.

PS: Да и надоело, если честно, это ежедневное «нытье» в комментариях о депрекации QBS. Вышло уже несколько релизов «от сообщества», а народ все ноет и ноет.
Просмотр регистров периферии уже есть в QtC 4.11, но только для GDB. Но кейловский отладчик прикручен в QtC 4.12 (пока только для симулятора и STLink для STM32, т.к оч много работы, не успеваю физически), но там пока без просмотра регистров (просмотр регистров с кейловским отладчиком уже закоммичен в QtC > 4.12).
Не совсем понял проблему. Кто мешает выполнить сборку последовательно под разные профили?

qbs build profile:stm32
qbs build profile:x86


Или же можно собрать все сразу под несколько профилей:

$ qbs build -f foobar.qbs debug-gcc profile:gcc debug-clang profile:clang
Это все там работает, это самое первое что работало, еще с незапамятных времен.
Сможет ли сообщество продвигать систему сборки?


Если честно — я не знаю… Думаю, что потихоньку что-то будет улучшаться.

В том же QtC, сейчас есть тестовый скелет для сборки при помощи CMake.


Да, там идет подготовка к переходу Qt && QtC на сборку используя CMake (но там же есть и ветка для сборки Qt при помощи QBS).

В принципе, в QBS сейчас есть все что нужно. По крайней мере, мне не доводилось сталкиваться с ситуацией, когда бы мне чего-то не хватало (хотя, скрипя сердцем признаться — кое где были случаи, но они уже решены).

Здесь речь идет как бы о программирования голых железок используя разные компиляторы (не только GCC). Возможно, у QBS здесь будут кое-какие шансы. Хотя, я знаю что и в CMake, в ее последних версиях уже есть поддержка того же IAR, KEIL и пр. Но я не щупал еще всерьез, лично для меня это пока муторно и сложновато.

Information

Rating
Does not participate
Registered
Activity