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
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.
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
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.
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.
Related
I am on MacOS 10.13.3, using Xcode 9 as my IDE, and trying to include Qt 5.10 in my Xcode project. I have installed Qt (with docs and examples) with Homebrew and ran many of them in QtCreator. Everything worked well up to this point.
My Xcode project is an extensive, complex project, the development of which has been active for a few years now, so switching to QtCreator or changing the structure of my project is not an option. I really need to add Qt to my existing Xcode project, which IMHO should be quite a natural thing to do given that Qt is a software development framework. However I have not been able to accomplish that yet. The upside is that in the process I have been learning quite a bit about Qt and its ecosystem. I now know how to use qmake, how to set up and successfully compile a project in QtCreator and how to create an Xcode project from QtCreator using qmake. As I said, I have been running many Qt examples and read pretty much every piece of documentation, blog and SO post I could find about this subject. To my surprise I haven't found a direct solution to this problem anywhere on the net.
So far I have included in my Xcode environment QtCore.framework, QtWidgets.framework and QtGui.framework, configured Xcode with the right search paths (Qt finds its files and frameworks) and include the right Qt headers in the code. However upon building my target I get a series of meaningless compilation errors.
Basically - if my understanding is correct - I can't just import Qt's components and frameworks I need, and set the right paths in Xcode just like I would do with any other framework. Qt 'features' a preprocessing step using MOC and UIC that sets it apart from other tools. So I examined the output of qmake and there are two files that the building system produces - qt_makeqmake.mak and qt_preprocess.mak which I think are responsible for the code generation step. Basically this is what I don't know how to translate into my Xcode environment.
Please feel free to tell me if my approach is not correct.
I am open to any advice or suggestion.
I would really like to integrate Qt into my project as Qt is such a powerful and complete framework. I hope someone will be able to help.
Thank you.
1 / In addition to setting the right path to Qt libraries and header files, which is fromwhat you said already done, you need to invoke the moc (Meta-Object Compiler) on your own Qt class which includes the Q_OBJECT macro. (basically every class you have made that are using signal/slot system).
MOChttp://doc.qt.io/qt-5/moc.html
This step must be done BEFORE compiling the project, and the result (the cpp generated moc files) must be compiled AND linked.
Now I am not an expert in XCode and MacOS development but for sure you have a way to add a custom step in your build process for doing that
2/ For UIC files : follow approximatively what is explained here (answer of Preetam, not the one validated) to obtain a .cpp and an .h file that you must include in your project too.
Hope this answer will help and point you toward the rigth direction.
Here is a post explained more in detail what I explained :
https://fmilicchio.bitbucket.io/2013/01/xcode-and-qt4-and-qt5/?
I have finished with my "Study Timer" project which I had developed in c++ using SDL and an eclipse IDE but I am new to Eclipse and I would like to know about a way to get Eclipse to produce a new package out of my project which i can directly supply to the end user (similar to how a .swf file is created after publishing a Flash project) that does not contain the various files and folders required only for compilation!.
Specifically:
I have many files and folders in my project that are necessary for development but not for execution!
For example, my project contains: src/ , headers/ , images/ , fonts/ ,Debug/ (contains the actual exe file) , other dll files required to compile and run...
But for execution, I only need the Debug/ , images/ , and Fonts/ !
Is there a way by which Eclipse can automatically generate a clean finished project that can be supplied to the end user?
Is is possible to produce a new executable file that is not dependant on the images and fonts folder but rather have them embedded to produce a larger .exe file (similar to a .swf that contains all the dependant media)?
For a C++ project in order to deploy it to end-users, you just need the executable(s) applications plus any system-specific dependencies (you can inspect them with Dependency Walker and find the installer for the redistributables or package them along with your app). Notice that C++ executables are NOT portable across platforms, so if you compile an exe file for Windows, it will NOT run on Linux or Mac.
Then you might need an installer to deploy everything and install it (if install is needed at all) into another user's system:
A free and easy to use one: http://www.jrsoftware.org/isinfo.php
A professional and opensource not-so-easy-to-use one: http://nsis.sourceforge.net/Main_Page
A commercial professional one: http://www.installshield.com/
Not sure: if you're asking for "what should I give the users from my Eclipse C++ project?" then you should give them a Release version of your application. Release means "optimized and without debugging aid", it will almost surely be faster and smaller than your Debug-folder executable. Then package it as I described above.
In Eclipse you can switch to "Release" (assuming a standard C/C++ Eclipse IDE) from
Build Configurations->Set Active->Release
As already stated, a Release version doesn't contain debugging code (useless for an end-user and even potentially dangerous if you have code that you would like users not to know anything about), it is optimized (debugging code is easier to read even in assembly mode and easier to analyze for bug trackings) and thus the executable is often way smaller in size.
After question update: for your executable to use embedded resources (i.e. reference things inside its own binary executable rather than relying on outsie files) you need a resource file to include and link into your executable. This depends on the compiler as well (Eclipse is an IDE, something that helps you writing code but it's not the program that really creates your exe file.. something that lies under the hood of Eclipse and to which Eclipse "communicate" what to generate).
I'm not sure if this is too general, so if it is I'll say that I'm on Linux using qmake, but I'd like to be able to switch from Linux to Windows with my project whenever I need to, as well as, possibly other PCs.
In order to do this, I'd like to know how some of the programmers on here have gotten around using resource directories without using absolute path definitions. With Qt, it seems like the runtime working directory is the build directory of the application, and not the source directory.
Ideally, I think the best solution would be to somehow get the Resource directory as it resides in the source directory and copy that to the relative build directory (i.e., Debug or Release, depending on development stage) so that the application can access that via run time.
This can introduce some complication, however (at least, I think it can).
Anyway, what would be a good solution to do this?
If you are using Qt. I would suggest using deploy process.
http://doc.qt.digia.com/qtcreator/creator-building-running.html
Basically, you just need to declare which directories need to be copied.
The qt creator will copy those dirs to build dir(release/debug) after build process is done.Then you simply run the executable.
Here is one of example.
https://github.com/longwei/incubator-cordova-qt.
in the pro file
wwwDir.source = www
xmlDir.source = xml
qmlDir.source = qml
DEPLOYMENTFOLDERS = wwwDir xmlDir qmlDir
second
include(deployment.pri)
qtcAddDeployment()
then it is done.
Its not clear what exactly you're trying to achieve, but perhaps a simple solution would be for the build scripts to pass the necessary path via a compilation definition (-D with gcc). Then depending on if its a Debug, Release, etc build, the definition would be set accordingly, then the corresponding binary would have the correct path.
As a side note, I tried qmake for a while, but found SCons to be much more versatile.
In my project, I use QWizard and QWizardPages, but at last I found these classes have too much restrict, and I want to modify their source code. But I think it's not a good idea to directly modify qt source, but copy them to my project folder and rename the class names. Is their somebody do the same thing before? I can't compile the files successfully, it seems qMywizard.cpp include the generated moc file of qMywizard.h at the end, and the moc file can't be compile without the QMyWizardPrivate definition. I'm also afraid that many macros can't be recognized when files change location. Can anyone give me some advice?
Qt source is in git. Clone it, make a branch, write your modifications there and compile it with their build system. Also, make sure to understand and follow the license obligations on modifications (especially if you are using the LGPL).
I am new to SVN and I want to commit a code to SVN using TortoiseSVN. I have C++ headers and source of the code, but I don't know how to organize the folders in an efficient way before uploading the version to SVN. Any suggestions about how people usually do? Is there any difference between the structure of codes for different languages, for example C++ or java. Should I follow any specific rules?
Update
So after checking the answers I made things a bit clearer. An usual folder structure is the following for one proyect:
/trunk
/branches
/tags
But I also found a similar structure that I liked a lot, which is:
/trunk #Keep it to developement mode always.
/samples #samples of use
/modules #software modules
/project_modName
/include # .hpp files
/src # .cpp files
/test #unitary tests
/branches #experimental developements (copies of trunk at various stages)
/tags #estable versions
/extras
/3rdparty #libs
/data #necessary data for developement
/doc #documentation
/resources #for window applications
At least I like it for multimedia applications code.
UPDATE 2
This update is just to explain how I am creating my repository. I created a folder called structure_svn. Inside I created the structure showned above. I right click on the parent folder and select import. In URL I write the folder path (file:///c:/svn_repos) so automatically the structure is created under svn_repos, without the folder structure_svn.
I want to remark this beacause the folder you right-click on to import will never appear. I just realized when I tried it, and also is explained on toturials.
The next step is to successfuly divide my code inside the created structure.
Here's how I structure my tree in a programming project (mainly from a C/C++ perspective):
/
src — Source and header files written by myself
ext — External dependencies; contains third-party libraries
libname-1.2.8
include — Headers
lib — Compiled lib files
Donwload.txt — Contains link to download the version used
ide — I store project files in here
vc10 — I arrange project files by IDE
bin — Compiled binaries go here
obj — The compiler's build files
gcc — If your project size justifies it, make a separate folder for each compiler's files
doc — Documentation of any kind
README
INSTALL
COPYING
makefile — Something to automate generation of IDE project files. I prefer CMake.
A few notes:
If I'm writing a library (and I'm using C/C++) I'm going to organize my source files first in two folders called "src/include" and "src/source" and then by module. If it's an application, then I'm going to organize them just by module (headers and sources will go in the same folder).
Files and directories that I listed above in italics I won't add to the code repository.
Edit: Note that I'm using Mercurial, not SVN, so the structure above it tailored for that version control system. Anyway, I see from your update that you already found one that you like.
One huge step forward is making sure all your projects do out-of-source builds, ie put temporary file in $TEMP and put all output file in a dedicated bin/lib directory. If done properly, this leaves you with source directories containing only source. What's in a name.. Apart from 'pure' source files also make sure that everything needed to build the source is in the repository: project files/generators, resources.
Once you got that in place correctly, there's a good chance you only have to put some typical project generated files (like *.suo for Visual Studio) into SVN's ignore list, and you're ready for commit.
Basically you can put in svn just what you want. The only standard you might consider to follow here is the standard repository layout: See here:
Within the project you are right that there exists several best practices. And they are different for each language. E.g a Java Package is organized by namespace. In the C++ world I have seen two main ways how to organize it:
Every Class into a header (.h) and a source file (.cpp) inside the same directory
Header and source is separated (so you have an folder especially for headers) This is usefull for libraries so that this path can be used by upper layer projects.
Then you need a folder for third party libs, another one for the target files and others such as build files or documentation.
You have a good explanation in the next Link if you are noob with svn!!