Развертывание QML приложения

<RCC>
    <qresource prefix="/">
        <file>main.qml</file>
        ....   
    </qresource>
</RCC>

Рекомендуємо хостинг TIMEWEB

Стабільний хостинг, на якому розміщується соціальна мережа EVILEG. Для проектів на Django радимо VDS хостинг.

добавь в pro
CONFIG += qtquickcompiler

у меня windeployqt --qmldir тоже собирает 100500 файлов. И сдеди них немало *.qml. Но среди них только qml из состава QML (например QtGraphicalEffects). Но ни каких main.qml, и я тоже все свои исходники я убрал в ресурсы.

ps не сразу понял суть вопроса. Нужно избавиться от базовых QtGraphicalEffects? А зачем? Это не "как вы выразились" файлы для разработчика, это файлы для работы программы.

Если сбор 100500 файлов это обычная практика, и заморачиваться не стоит, пусть так. При windeployqt проект полон к примеру файлов стилей Fusion, Imagine, Material, Universal. Вот для работы программы, которая использует один стиль, зачем все таскать. Да и .qml при удалении оставляют программу рабочей (деплой уже подготовил .qmlc). Назвал я эти файлы "для разработчика" потому что они часть исходников смого Qt. Отсюда и возник вопрос, готовая собранная программа обязана содержать такое количество файлов-исходников, которые в таком виде(.qml) пользователю ПО вообще не нужны. (достаточно бы и .qmlc). (мы же не предоставляем, например, прошивки пользователю в .с файле, который он может открыть, для пользователя достаточно уже готового .hex или .bin).
Но повторюсь, я услышал от Вас что данная практика считается нормальной, и при динамической сборке много чего тут не придумаешь.

не совсем удачное сравнение QML с СИ. QML - это интопретируемый язык, СИ - это компилируемый. Сравните QML с JS или питоном. Конечная программа - это есть исходный код (хотя есть способы из питона получить пуре .ехе, например gimp)
У нас скаду прогеры писали на Qt, а GUI на qml. Конечный продукт был exe+dll+кучаQml. Причем .qml не только базовые, но и все самописные исходные (аля myFile.qml). Весь гуй шол на qml и исходниками лежал рядом с ехе. Если исправлялась ошибка в гуях, то у конечного пользователя обновлялся только соответствующий *.qml файл.

Из-за "интерпритации" раньше гуи на qml работал гораздо тормознутее, чем на Qt. Но сейчас современные ПК шустрые и этой разници особо не видно. Также добавили qtquickcompiler. А вот если писать ПО для ембеддед со слабым GPU, то иной раз эта интерпритация подтормаживает. Например при смене раскладки виртуальной клавиатуры rus-en en-rus, такое чувство, что идет компиляция новой клавиатуры и только после прорисовка. Конечно хотелось бы чтобы вся компиляция QML произошла на этапе сборки ПО и при выполнении был только машинный нативный код, чтоб было уже две готовых клавиатуры и было-бы быстрое переключение.

Полностью согласен, что пример не удачный, но я так как раз попытался выразить то, что вы далее описали с примером со скадой, часть .dll и часть .qml с интерпритацией.
И в Вашем ответе я увидел что меня и интересовало - нету (и их не надо искать) способов перевода всего .qml приложения в машинный код на этапе сборки ПО. Сапасибо.