Слоган Qt:
Пишите один раз, компилируйте везде.
Имея это в виду, Qt официально не предлагает готового решения для кроссакомпиляция приложений Qt с конкретной платформы на другие платформы.Несмотря на то, что Qt, безусловно, выполнимо, если потратить много времени и усилий, хорошая общая практика предложит вам создать приложение Qt непосредственно на целевой платформе.Это означает, что создайте свою цель Windows для своего приложения на машине Windows, свою цель Mac на машине Mac и цель Linux на, как вы уже догадались (:-)), машину Linux.
Это так«Пиши один раз, собирай везде», на мой взгляд, очень удачно подобранная комбинация слов.В противном случае строка тэга могла бы звучать так: «Пиши один раз, компилируй для всего».
Возвращаясь к исходному вопросу, вам даже не понадобятся разные физические машины для каждой целевой платформы, поскольку в этот деньи век хороших решений для виртуализации вы можете легко настроить пару виртуальных машин и создать приложение на разных платформах с одной и той же физической машины.
Что касается других вопросов, на которые ваш вопрос не получил прямого ответа:
Должен ли я просто установить Qt Creator на всех трех платформах?Если я сделаю это, могу ли я ожидать, что смогу взять проект Qt (или, может быть, просто исходный код), который я разработал с использованием, например, Qt Creator для Windows, скопировать его на мой компьютер Mac или Linux и собрать еготам используется версия Qt Creator для этой платформы, без каких-либо серьезных проблем?
Да.Незначительные проблемы, такие как получение значков исполняемых / двоичных файлов ваших приложений прямо на всех трех основных платформах (Windows, Linux, Mac) или расширенная интеграция с док-станцией Mac Dock или панель задач Проблемы интеграции между ними.Эти проблемы можно решить, не нарушая кросс-платформенную характеристику вашего кода, путем правильной инкапсуляции кода, специфичного для вашей платформы, в директивах компилятора, таких как, например, #define.Я также рекомендую делать это для каждого кода, специфичного для конкретной платформы, который требуется вашему приложению, или если вы будете широко использовать код, специфичный для платформы, разделив целые блоки кода, относящегося к конкретной платформе, на несколько динамически загружаемых библиотек (или общих библиотек), специфичных для каждой платформы, ноэкспорт того же абстрактного универсального интерфейса и загрузка / связывание с ними по мере необходимости.
Возможно, это даже лучший способ использования Qt для создания исполняемых файлов для нескольких платформ вместо установки инструментов кросс-компиляции наодин узел разработки?
Вы должны использовать Qt SDK (Qt Creator или инструменты командной строки) для сборки вашего приложения везде, где это возможно, поскольку такие инструменты, как qmake, возьмут на себя бремя обработки файлов .moc вручную в вашемMakefiles.Но если это становится невозможным по нескольким причинам, например.Как ваша компания навязывает разработку Visual Studio (кросс-платформенный, да?), есть много учебников о том, как обрабатывать сборки на основе Qt с использованием систем сборки, таких как MS Visual Studio, GNU autotools или CMake.Хотя я бы порекомендовал придерживаться qmake, который является хорошим генератором «make makefile» и легко адаптируется под любые хаки для конкретных платформ, которые могут понадобиться вашему приложению для правильной сборки, вместо того, чтобы использовать систему сборки, которая более удобна для хаков для конкретной платформы.и затем пытается удовлетворить потребности Qt в этих системах сборки.В конце концов, если вы разрабатываете свое приложение на Qt по кроссплатформенным причинам, то Qt должен быть основной платформой для вашего приложения, а не API / кодом для конкретной платформы или сторонними библиотеками, которые вы могли бы использовать.
Я надеюсь, что ябыли достаточно ясны и полезны.
PS: Я также приветствую предложения или исправления / дополнения относительно того, что я написал в комментариях.