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).
Related
I want to ask something that might sound stupid but I dont know how to get over it.
I wrote a C++ program with some header files and 2 cpp files, one of which includes main.In the header files there are the definitions of some classes I created that have some inline functions and some functions that I declared in the classes and defined in one of the cpp files (not the one with main).
The program compiled and run fine but I wanted to change a few details in some of the inline functions of the classes. I did those changes and the program compiled and ran BUT it was using the previous version of the header files and not the new one.
I have tried creating a new project using the new files but even then the program will actually use their old version.
I am using Dec-C++5.11 in windows 10.
Solved. Looks like I needed to change the file name. Thank you very much!!
Some build systems will only perform "incremental" builds, so if you change a source file then that source file is recompiled, but unless you rebuild the whole project your original header content may still be used. This is even more so the case if you are using precompiled headers, and it may also affect inline functions in that their content has already been "inlined" into source files for whom a rebuild is not being triggered.
Changing the header's filename will work around this "cache" in many cases, but the correct (and far more user-friendly) approach is to ensure that you instruct your IDE to rebuild the entire project from scratch. In Dev-C++, that option is called "Rebuild All". I would generally recommend this option whenever you alter a header file.
(If you were using GNU Makefiles, you would perform make clean before your next make all).
I am trying to use gnuplot++, but this is really a more general question about downloaded source code. I have downloaded the gnuplot++ source code and it consists of multiple .h and .cc files. I would like to use it in othercopy projects in the future so I am reluctant to add all the files into my project directory.
From what I understand gcc will look in /usr/local/include for header files, so I have put the code there for now. But what is the best way to compile and link the code?
Should I use the makefile to include the directory of the source code?
Should I keep it somewhere easy to find like /usr/local/include?
How do I know the best way to compile the code in gnuplot++?
Typically, if the project itself doesn't come with install instructions, I usually add it somewhere "public", e.g. /usr/local/project/{lib,include,src,...} where "project" in this case would be gnuplot++.
In this case, there doesn't appear to be any support for building this into a library, which makes it a little more awkward, as you need the sources included in your project itself. I'd still keep those sources separate, but you may prefer to just put them into a separate directory within the project [or spend an hour or three making a library of it].
For general practice, yes, keep the source for gnuplot++ (or any other similar 3rd-party project) separate from your own application source code. This makes it much easier to manage updates to the 3rd party projects, etc.
Yes, I would use the makefile for your application to also include the path to the headers for gnuplot++ and I would not copy those files directly into /usr/local/include. Instead, I would consider a couple options: do nothing and point your include path in your makefile to the gnuplot++ directory, or put symbolic links in /usr/local/include to point to the gnuplot++ files.
As for the best way to compile gnuplot++, I would have to look at gnuplot++ myself and see what it has to say, perhaps in a README file or similar.
In general, when using third-party libraries, you build and install those libraries according to the installation description that comes with the downloaded source.
If there is no installation guideline, it is typically a set of steps like
./configure
make
make install
Then it is the responsibility of the library to ensure the relevant headers and library files are easily locatable for use in your project.
gnuplot++ is an exception here, because it does not seem to come with its own build structure.
The best advice in cases such as this is to put the source from gnuplot++ in a directory within your project (possibly parallel to your own sources) and include the files in your own build setup.
I'm a beginner starting to use Microsoft Visual C++ Express 2010 for Windows Programming. I've created a new C++ application using native code, not managed or MFC. I had Visual Studio create for me the basic windows code to create one window with simple menus (chat.cpp). I modified this file and I was able to compile correctly and see my changes take effect.
Now I've added one more source file to the solution (intro.cpp) which I include in my header and call from within chat.cpp. This seems to work just fine, but with one problem. The compiler doesn't seem to be applying my code changes occasionally: I make various edits, recompile, and the "old" code seems to be running. Then, after a while, after I make only a tiny modification, the compiler seems to "catch up" and it runs the new code including all the previous changes I had made.
Is there some kind of cache? Do I need to tell the compiler which files to compile and which ones to just link from object files? Did I make a mistake when I added the file to the solution?
Does intro.cpp have a header file? is that in your solution too?
It's hard for me to imagine that this area of such a mature IDE has a bug here, so I would examine your file list first. Make sure that the Solution Explorer shows all the files you have added and are editing. This is the list that VS uses to determine rebuild is needed.
EDIT: I admit it's not clear to me from your description why it would fail right now. However, typically header files do not include code, it works the other way around (except for class template header files, such as the STL headers). There is some discussion about pros and cons here. The most compelling argument to me in favour of code including headers rather than vice versa is that the header file contains the interface, while the code file contains the implementation.
I would try restructuring your code to a more traditional structure where intro.cpp includes intro.h and any others it needs, and the same with chat.cpp. Then your compilation units are intro.cpp and chat.cpp, and they depend on the associated header files, so provided they are properly listed in the SOlution Explorer, all should work. You can clean up the build dependencies to avoid dups and reduce build time once you have it working as you wish.
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.
We are migrating our works repository so I want to do a cull of all the unreferenced files that exist in the source tree before moving it into the nice fresh (empty) repository.
So far I have gone through by hand and found all the unreferenced files that I know about but I want to find out if I have caught them all. One way would be to manually move the project file by file to a new folder and see what sticks when compiling. That will take all week, so I need an automated tool.
What do people suggest?
Clarifications:
1) It is C++.
2) The files are mixed. I am looking for files that have been superseded by others but have left to rot in the repository - for instance file_iter.h is not referenced by any other file in the program but remains in the repository just in case someone wants to compile a version from 1996! Now we are moving to a fresh repository we can safely junk all the files that are no longer used.
3) Lint only finds unused includes - not unused files (I have the 7.5 manual in front of me).
You've tagged this post with c++, so I'm assuming that's the language in question. If that's the only thing that's in the repository then it shouldn't be too hard to grep all files in the repository for each filename to give you a good starting point. If the repository contains other files (metadata, support files, resources, etc) then you're probably going to need to do it manually.
I can't offer an existing tool for it, but I would expect that you can get a lot of this information from you build tools (with some effort, probably). Typically you can at least let the build tool print the commands it would run, without actually running them. (E.g. the -n option of make and bjam does this.) From it you should be able to extract at least the used source files.
With the -MM of g++ you can get all the non-system header files for the given source files. The output is in the form of a make rule, but with some filtering this shouldn't be a problem.
I don't know if this helps; it's just what I would try in your situation.
You can actually do this indirectly with Lint by running a "whole project analysis" (in which all files are analysed together rather than individually).
Configure it to ignore everything but unreferenced variable/enum/function etc warnings and it should give you a reasonable indicator of where the deadwood lies without those issues being obscured by any others in the codebase.
A static source code analysis tool like lint might do the job. They will tell you if a piece of code will never be called.
Have you taken a look at Source-Navigator? It can be used as an IDE but I found to be very good at analyzing source code structure. For example, it can find out where and if a certain method is used in your source code.
I don't know if it's scriptable but it might be a good starting point for you.