What is the purpose of the garbage (files) that Qt Creator auto-generates and how can I tame them?

Question

I'm fairly new to Qt, and I'm using the new Nokia Qt SDK beta and I'm working to develop a small application for my Nokia N900 in my free time. Fortunately, I was able to set up everything correctly, and also to run my app on the device.

I've learned C++ in school, so I thought it won't be so difficult. I use Qt Creator as my IDE, because it doesn't work with Visual Studio.

I also wish to port my app to Symbian, so I have run the emulator a few times, and I also compile for Windows to debug the most evil bugs. (The debugger doesn't work correctly on the device.)

I come from a .NET background, so there are some things that I don't understand.

When I hit the build button, Qt Creator generates a bunch of files to my project directory:

• moc_*.cpp files - what is their purpose?
• *.o files - I assume these are the object code
• *.rss files - I don't know their purpose, but they definitely don't have anything to do with RSS
• Makefile and Makefile.Debug - I have no idea
• AppName (without extension) - the executable for Maemo, and AppName.sis - the executable for Symbian, I guess?
• AppName.loc - I have no idea
• AppName_installer.pkg and AppName_template.pkg - I have no idea
• qrc_Resources.cpp - I guess this is for my Qt resources

(where AppName is the name of the application in question)

I noticed that these files can be safely deleted, Qt Creator simply regenerates them. The problem is that they pollute my source directory. Especially because I use version control, and if they can be regenerated, there is no point in uploading them to SVN.

So, what the exact purpose of these files is, and how can I ask Qt Creator to place them into another directory?

Edit

What Rob recommended seems to be the most convenient solution, but I marked Kotti's answer accepted, because he provided me with the best explanation about how Qt's build mechanism works.

The solution

It seems that neither the Maemo nor the Symbian toolchain supports shadow builds as of yet, so I use these in my project file to solve the situation:

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

Glissando

It may take some research, but you should be able to figure out a way to make those files go elsewhere. (We're building Qt apps but not using QMake so I can't give you specifics for that; I just know that the tools will put the files wherever you want them.) – Nonresident

@Nonresident - I'm curious, what tool do you use to compile and build, if not QMake? – Glissando

An internal tool derived from Jam. – Nonresident

Answer 1

Not a fully answer to your question, but just part of it :) Also, it's googlable.

Guess that if you develop in C++, you should know what does Makefile stand for. Also I think the .loc file is generally a file with localized strings / content.

_{(source: thelins.se)}

Comparing the C++ build system to the Qt build system, you can see that the C++ build system, (the gray boxes), are left unmodified. We are still building C++ code here. However, we add more sources and headers. There are three code generators involved here:

The meta-object compiler (moc in the illustration) – the meta-object compiler takes all classes starting with the Q_OBJECT macro and generates a moc_*.cpp C++ source file. This file contains information about the class being moc’ed such as class name, inheritance tree, etc, but also implementation of the signals. This means that when you emit a signal, you actually call a function generated by the moc.

The user interface compiler (uic in the illustration) – The user interface compiler takes designs from Designer and creates header files. These header files are then included into source files as usual, making it possible to call setupUi to instanciate a user interface design.

The Qt resource compiler (rcc in the illustration) – The resource compiler is something we have not talked about yet. It makes it possible to embedd images, text files, etc into your executable, but still to access them as files. We will look at this later, I just want to include it in this picture where it belongs.

I hope this illustration clarifies what Qt really does to add new nice keywords to C++. If you are curious – feel free to read some of the generated files. Just don’t alter them – they are regenerated each time you build your application.

If you are using QtCreator, the moc files are generated in the debug and release sub-directories of your project directory. The uic files are stored in the root of the project directory. The rcc files are generally boring, but I’m sure that you can find them in your project directory hierarcy somewhere.

---

Edit: You don't have to include these files into your SVN. This is pretty the same crap as commiting .ncb, .pdb and other temporary files. Every time you change something in your Qt application, these temporary files get regenerated as an update to your changes, so there is no sense to commit them to SVN.

Neuralgia

@Kotti - Thank you very much! However, they are really all placed into the root directory of my project. I would be happy if I could get it to place them into a debug or bin directory. – Glissando

As I remember how I did Qt things (I used Visual Studio + Qt), there was a settings window where you could specify where to place these generated files. In my case it was set to GeneratedFiles and I didn't even think about it. I'm pretty sure there should be the same switch in Qt Creator. Also, why did you say Qt doesn't work with VS? – Neuralgia

@Kotti - I say because it doesn't work. It doesn't let me create a new project. Possibly it is messed up by some othe VS extension. But it doesn't matter, because I don't think it is possible to delelop for mobile devices with it. (At least, I couldn't find any resources about it.) – Glissando

@Kotti - Tip: if you begin your comment with @Venemo, SO will notify me that I got a new response. :) – Glissando

@Glissando I also doubt it's possible. Anyway, Qt integration into Visual Studio is extremely convinient, at least for me, so I may even say that's it's actually worth reinstalling Visual Studio and spending a lot of time in order to make it work. Also, thanks for pointing at that @ trick :) – Neuralgia

@Kotti - I have both VS 2008 and VS 2010, so no need to reinstall... I'm a .NET dev mostly, this is why I have such noobish questions about Qt. :) – Glissando

Answer 2

You can tell qmake (and therefore QtCreator) to put the generated files elsewhere by adding the following to your .pro file for the project

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

This would put all ui files in the .ui directory, moc files in the .moc director and all .o files in the .obj directory. (Of course you can change these as you like)

The relevant help for qmake is at: http://doc.qt.io/archives/4.6/qmake-variable-reference.html#moc-dir

Bainbrudge

Answer 3

If you use shadow builds (enabled by default in the Qt Creator 2.0 beta) then all of these temporary files are created in a separate folder. For example:

\MyProjects\ProjectFoo
\MyProjects\ProjectFoo-build

Very useful IMHO.

Perihelion

Thanks, I'll check it out. It will be weird that I'll have 3 different versions of Qt Creator, however. :P – Glissando

I discovered that Qt Creator v.1.3.83, which is in Nokia Qt SDK by default, is the same as 2.0 beta 1. Still, these files are created in the source folder. Could you please tell me where to enable the setting you are talking about? – Glissando

Select the Projects view and then the Build page. The shadow build settings should be in there - it may be that it is enabled but the folder location is the same as the project. – Perihelion

Thank you! I found it. The next problem is, "Building in subdirectories of the source directory is not supported by qmake." But I think I can get around this one. – Glissando

Answer 4

Don't try to get the files stored in another directory; rather, tell subversion to ignore them, as explained at http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.ignore.html , for example.

Most source control systems have good support for ignoring generated files, since this is a problem hit by almost every single software project.

Kaleykaleyard