Какова цель мусора (файлов), что Qt Creator Auto-генерирует и как я могу их приручить?

Question

Я довольно новичок в Qt, и я использую новый Nokia Qt SDK Beta, и я работаю над разработкой небольшого приложения для моей Nokia N900 в свободное время.
К счастью, я смог все правильно настроить, а также запустить свое приложение на устройстве.

Я узнал C ++ в школе, поэтому я думал, что это не будет так сложно.
Я использую QT Creator в качестве моей IDE, потому что он не работает с Visual Studio.

Я также хочу портировать свое приложение в Symbian, поэтому я несколько раз запустил эмулятор, и я также скомпилировал для Windows для отладки самых злых ошибок. (Отладчик не работает правильно на устройстве.)

Я пришел с .NET Background, так что есть некоторые вещи, которые я не понимаю.

Когда я нажимаю кнопку сборки, Qt Creator генерирует кучу файлов в моем каталоге проекта:

• moc_*.cpp Файлы - я не знаю их цели. Может кто-нибудь сказать мне?
• *.o Файлы - я предполагаю, что это объектный код
• *.rss файлы - я не знаю их цели, но у них определенно нет ничего общего с RSS
• Makefile а также Makefile.Debug - Не имею представления
• AppName (без расширения) - исполняемый для Maemo, а также AppName.sis - Исполняемый для Symbian, я думаю?
• AppName.loc - Не имею представления
• AppName_installer.pkg а также AppName_template.pkg - Не имею представления
• qrc_Resources.cpp - Я думаю, это для моих QT Resources

(куда AppName Имя рассматриваемого приложения)

Я заметил, что эти файлы могут быть безопасно удалены, Qt Creator просто восстанавливает их.
Проблема в том, что они загрязняют мой исходный каталог. Особенно потому, что я использую контроль версий, и если они могут быть регенерированы, нет смысла зарабатывать их на SVN.

Итак, может ли кто-нибудь сказать мне, какова точная цель этих файлов, и как я могу спросить Qt Creator разместить их в другой каталог?

РЕДАКТИРОВАТЬ:

Похоже, я узнал больше от ответов на этот вопрос, чем я думал, что буду. :)
Большое спасибо всем, кто мне помогли. Я дал каждому Упитету, потому что я мог узнать что-то новое от каждого ответа.

На самом деле, какая графство рекомендуется, кажется наиболее удобным решением, но я отметил ответ Kotti, потому что он предоставил мне лучшее объяснение о том, как работает механизм сборки QT.

Решение:

Похоже, что ни Maemo, ни Symbian Shoolchain поддерживают тень, поскольку пока еще, поэтому я использую их в моем файле проекта, чтобы решить ситуацию:

DESTDIR = ./NoSVN
OBJECTS_DIR = ./NoSVN
MOC_DIR = ./NoSVN
RCC_DIR = ./NoSVN
UI_HEADERS_DIR = ./NoSVN

Answer 1

Не полностью ответить на ваш вопрос, но просто часть этого :) Кроме того, это многообещается.

Угадай, что если вы разрабатываете в C ++, вы должны знать, что делает Makefile стоять за. Также я думаю, что .loc Файл, как правило, файл с локализованными строками / контентом.

_{(источник: TheLins.se.)}

Сравнивая систему сборки C ++ к системе сборки QT, вы можете увидеть, что система сборки C ++ (серые коробки) остаются немодифицированными. Мы все еще строим код C ++ здесь. Однако мы добавляем больше источников и заголовков. Здесь участвуют три генератора кода:

Meta-Object Compiler (MOC на иллюстрации) - Компилятор Meta-Object принимает все классы, начиная с макроса Q_Object и генерирует MOC _ *. Исходный файл CPP C ++. Этот файл содержит информацию о классе, являющемся мокаментом, таким как имя класса, дерево наследования и т. Д., Но также реализация сигналов. Это означает, что когда вы излучаете сигнал, вы действительно называете функцию, создаваемую MOC.

Компилятор пользовательского интерфейса (UIC на иллюстрации) - Компилятор пользовательского интерфейса требует дизайна от дизайнера и создает заголовочные файлы. Эти файлы заголовка затем включены в исходные файлы как обычно, что позволяет вызывать Setupui для создания дизайна пользовательского интерфейса.

Компилятор ресурсов QT (RCC на иллюстрации) - Ресурсный компилятор - это то, о чем мы еще не говорили. Это позволяет встроить изображения, текстовые файлы и т. Д. В свой исполняемый файл, но все еще для доступа к ним в качестве файлов. Мы посмотрим на это позже, я просто хочу включить его в эту картину, где она принадлежит.

Я надеюсь, что эта иллюстрация разъясняет, что действительно делает QT, чтобы добавить новые приятные ключевые слова на C ++. Если вам любопытно - не стесняйтесь читать некоторые из сгенерированных файлов. Просто не изменяйте их - они регенерируются каждый раз, когда вы создаете свое приложение.

Если вы используете QtCreator, файлы MOC генерируются в подпаментах отладки и выпуска вашего каталога проекта. Файлы UIC хранятся в корне в каталоге проекта. Файлы RCC, как правило, скучно, но я уверен, что вы можете найти их в своем каталоге проекта Hierarcy где-то.

---

Редактировать: Вам не нужно включать эти файлы в свой SVN. Это довольно одно и то же дерьмо, что и комбитающая .ncb, .pdb и другие временные файлы. Каждый раз, когда вы изменяете что-то в своем приложении Qt, эти временные файлы регенерируются как обновление ваших изменений, поэтому нет смысла совершать их SVN.

Answer 2

Вы можете сказать qmake (и, следовательно, qtcreator), чтобы поставить сгенерированные файлы в другом месте, добавив следующее в файл .pro для проекта

UI_DIR = .ui
MOC_DIR = .moc
OBJECTS_DIR = .obj

Это поставило бы все файлы пользовательских интерфейсов в каталог .ui, файлы MOC в директоре .moc и все файлы .o в каталоге .obj. (Конечно, вы можете изменить их, как вам нравится)

Соответствующая помощь для Qmake находится на:http://doc.qt.io/archives/4.6/qmake-variable-reference.html#moc-dir.

Answer 3

Если вы используете тени сборки (включены по умолчанию в Qt Creator 2.0 Beta) Тогда все эти временные файлы создаются в отдельной папке. Например:

\MyProjects\ProjectFoo
\MyProjects\ProjectFoo-build

Очень полезно ИМХО.

Answer 4

Не пытайтесь получить файлы, хранящиеся в другом каталоге; Скорее, скажите Subversion, чтобы игнорировать их, как объяснено в http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.ignore.html. , Например.

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