> На уровне кода Qt 6, полагаю, сможет работать и на Win2k
Наврятли, т.к. там изменения не только связанные с отрисовкой. Начиная с версии 5.7 (если не ошибаюсь), минимальная версия Windows это 5.7. Там изменения, как минимум коснулись с работой с сетью, там используется теперь Win API из Windows 7 (которых нету в XP и ниже). Может и еще где что-то «обновили», не знаю… Я бы не надеялся на все что ниже 7-ки ))
Ах, ясно. Я почему-то думал, что 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 года, а поток этих «вбросов» всё не уменьшается.
Да, бывает(бывало) иногда. Но, может быть, это зависит от GDB провайдера. Например, последнее время я использую ST-Util, вместо OpenOCD. Вроде пока все более-менее стабильно было.
PS: Хотя, я не ковырял сам движок отладчика GDB, т.к. его «пилят» ребята из Qt-company. Попробуйте создать баг-репорт, может поможет. :)
Есть люди, заинтересованные в продолжении развития QBS. Тот факт, что от него отказались Qt-шники ничего не меняет. Есть очень хорошая (но маленькая) команда которая продолжает развитие.
PS: Да и надоело, если честно, это ежедневное «нытье» в комментариях о депрекации QBS. Вышло уже несколько релизов «от сообщества», а народ все ноет и ноет.
Просмотр регистров периферии уже есть в QtC 4.11, но только для GDB. Но кейловский отладчик прикручен в QtC 4.12 (пока только для симулятора и STLink для STM32, т.к оч много работы, не успеваю физически), но там пока без просмотра регистров (просмотр регистров с кейловским отладчиком уже закоммичен в QtC > 4.12).
Если честно — я не знаю… Думаю, что потихоньку что-то будет улучшаться.
В том же QtC, сейчас есть тестовый скелет для сборки при помощи CMake.
Да, там идет подготовка к переходу Qt && QtC на сборку используя CMake (но там же есть и ветка для сборки Qt при помощи QBS).
В принципе, в QBS сейчас есть все что нужно. По крайней мере, мне не доводилось сталкиваться с ситуацией, когда бы мне чего-то не хватало (хотя, скрипя сердцем признаться — кое где были случаи, но они уже решены).
Здесь речь идет как бы о программирования голых железок используя разные компиляторы (не только GCC). Возможно, у QBS здесь будут кое-какие шансы. Хотя, я знаю что и в CMake, в ее последних версиях уже есть поддержка того же IAR, KEIL и пр. Но я не щупал еще всерьез, лично для меня это пока муторно и сложновато.
Наврятли, т.к. там изменения не только связанные с отрисовкой. Начиная с версии 5.7 (если не ошибаюсь), минимальная версия Windows это 5.7. Там изменения, как минимум коснулись с работой с сетью, там используется теперь Win API из Windows 7 (которых нету в XP и ниже). Может и еще где что-то «обновили», не знаю… Я бы не надеялся на все что ниже 7-ки ))
Неистово плюсую этого господина, тем более, что уже готовится к релизу плагин для VSCode.
Кроме того комьюнити для Qbs пилит плагин для VSCode: github.com/denis-shienkov/vscode-qbs
Скоро анонс на хабр постараюсь добавить (плагин в принципе уже готов). ;)
Да, у 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.
Я как бы в таком случае много раз собирал Qt как то так (так, сказать, по-быстрому):
1. Берется и «сливается» rootfs из реального у-ва посредством rsync (или иным образом).
2. Берется любой готовый тулчейн (GCC) для ARM примерно той-же версии что и использовался на у-ве (просто ставим из репозитория на хост или качаем отдельно).
3. На хосте запускаем 'qemu-static-arm' (или как оно называется), чрутимся на скачанную rootfs и доустанавливаем 'devel' пакеты в rootfs (те, которые нужны для сборки, если, конечно, у железки есть свой репозиторий). Если репозитория нет — то придется собирать все недостающие пакеты кросс-компилятором и «устанавливать» в rootfs.
4. Собственно, всё, кросс-компилим Qt используя наш тулчейн и «нашу» rootfs.
PS: И да, как уже сказали выше — это самый быстрый и простой способ.
Что правда — то правда.
Постоянно в проектах предпочитал и предпочитаю использовать Qbs && QtC. Это гораздо проще и быстрее чем CMake (но это мое ИМХО, а так, конечно, всЁ на любителя).
Ну вот, опять… Не надоело еще? Везде где в темах упоминается о Qbs появляются такие личности, которые готовы что-то да вбросить… Прошло уже 2 года, а поток этих «вбросов» всё не уменьшается.
PS: Хотя, я не ковырял сам движок отладчика GDB, т.к. его «пилят» ребята из Qt-company. Попробуйте создать баг-репорт, может поможет. :)
PS: Да и надоело, если честно, это ежедневное «нытье» в комментариях о депрекации QBS. Вышло уже несколько релизов «от сообщества», а народ все ноет и ноет.
Или же можно собрать все сразу под несколько профилей:
Если честно — я не знаю… Думаю, что потихоньку что-то будет улучшаться.
Да, там идет подготовка к переходу Qt && QtC на сборку используя CMake (но там же есть и ветка для сборки Qt при помощи QBS).
В принципе, в QBS сейчас есть все что нужно. По крайней мере, мне не доводилось сталкиваться с ситуацией, когда бы мне чего-то не хватало (хотя, скрипя сердцем признаться — кое где были случаи, но они уже решены).
Здесь речь идет как бы о программирования голых железок используя разные компиляторы (не только GCC). Возможно, у QBS здесь будут кое-какие шансы. Хотя, я знаю что и в CMake, в ее последних версиях уже есть поддержка того же IAR, KEIL и пр. Но я не щупал еще всерьез, лично для меня это пока муторно и сложновато.