I have a Qt project with qmake.
After I generate the makefile, if I run make dist, the generated tarball will contain a bunch of .pri and .conf files that aren't part of my project but come from Qt. Is there a way to exclude these?
In any case shipping them with my sources is useless because they aren't sufficient to compile it.
Related
I have the following project structure:
/
general.pro
a/
a.pro
some files
b/
b.pro
some files
c/
Makefile
some files
general.pro is a TEMPLATE=subdirs style qmake-project. The two other project files are normal/common qmake project files (folder a and b). The third folder (folder c) contains a kernel module with the following Makefile: http://pastebin.com/Bv39D6KK
I'm wondering if that Makefile can be translated somehow to a qmake project file.
If not, is there a way to the the general.pro project file that there is a "c" folder containing a Makefile which should be ran too?
Regards
I really doubt, you can include Makefile in a .pro file.
Here is my thoughts about what you can do:
If c is your project, you could simply create one more .pro file for it.
If it is not, and you don't need to edit it, you could build it without including into subdirs (if it's a library, you are using in a or b, you still can build it, and then create a .pri file and add includes and libs etc).
If you need it for a build machine or for deploying, you could use build script.
You could use cmake.
Update:
It turns out, there is a solution.
Though, I could not make it work myself, I hope it helps. What you need is to add following lines to a top-level pro file:
mytarget.commands = make -C c
QMAKE_EXTRA_TARGETS += mytarget
PRE_TARGETDEPS += mytarget
Where c is a name of sub-directory, containing Makefile.
I have a project with some folders which happen to contain source files with the same names.
My source tree looks like this:
project.pro
foo/
conflict.h
conflict.cpp
bar/
conflict.h
conflict.cpp
some.h
other.h
files.h
main.cpp
Per default, qmake generates a Makefile which will produce a build tree like this:
conflict.o
main.o
target
Where conflict.o is the object file resulting for both foo/conflict.cpp and foo/conflict.h.
I can't to change their names because they are generated using an external tool and forcing different file names would imply to change their contents, so this is not an option.
I also don't want to use qmake SUBDIRS template because this would imply that (1) every subdir is built separately as a library and thus very much complicate the overall build process (in my eyes at least) and (2) in the top level directory I can't have any source files. Or am I wrong?
Can't I just tell qmake to write the object files into separate directories within the build directory? So my build tree will look like this:
foo/
conflict.o
bar/
conflict.o
main.o
target
Or are there any other solutions neither requiring to rename the source files nor introducing something complicated like static libraries? I just can't believe that Qt didn't solve this (in my eyes simple) problem for years. (I already hat this problem 4 years ago but could rename the files in that project, while here I can't.)
If it's important: I use Qt 4.8 on both Ubuntu with G++ and Windows with mingw32.
Are you tied to qmake? If not, an alternative could be to use cmake. I just verified your usecase with a simple CMakeLists.txt like
cmake_minimum_required (VERSION 2.6)
project (conflict)
add_executable(conflict foo/conflict.cpp bar/conflict.cpp main.cpp)
which even included a source file in the top level directory (main.cpp). This properly builds the executable - the object files are created in sub directories like
./CMakeFiles/conflict.dir/main.cpp.o
./CMakeFiles/conflict.dir/bar/conflict.cpp.o
./CMakeFiles/conflict.dir/foo/conflict.cpp.o
cmake also includes support for Qt4, to automatically pull in the required include paths and libraries. It might require some effort to migrate from qmake to cmake, but given the requirements you have I would give it a try.
What is the difference between *.pro and *.pri configuration files for qmake?
What should go into a *.pro file and what should go into a *.pri file?
There is one main difference between their targetted reuse:
.pro
This is usually called Project File.
.pri
This is usually called Project Include File.
As you can see in their names, the main difference is that .pri files are meant to be include files. That is similar to including modules in programming language to share the functionality, essentially.
You will be able to write the common settings and code into those .pri files and include them from several .pro files as the need arises. This is how you would use it in practice:
foo.pri
FOO = BAR
hello.pro
...
include($$PWD/foo.pri)
...
world.pro
...
include($$PWD/foo.pri)
...
This way, the commonality would be available both in hello.pro as well as world.pro. It does not make much of difference in this scenario, but when the shared functionality gets longer, it will save you some writing as well as sync'ing, bugfixing, and so on.
You could even include a .pri file inside another .pri file if you wish. You could also include .pri files in different subprojects, etc. It is very nice.
The syntax is the same, however, for both the .pro and .pri files. In the end, you would run qmake on the .pro files, and that is also what qmake generates for you if you do not have a project file existing and you intend to use qmake -project.
You can read more about the include function in here:
include(filename)
Includes the contents of the file specified by filename into the current project at the point where it is included. This function succeeds if filename is included; otherwise it fails. The included file is processed immediately.
You can check whether the file was included by using this function as the condition for a scope.
Just to be complete, there are also .prf Project Feature Files and .prl Project Linker Files, but as an end user, you do not need to deal with that for now.
A .pro file is what you would run QMake on. A .pri file is included by a .pro file. Other than that there is not much of a difference between the two.
Example usage could be if you have different builds which need different options. You could put shared information in the .pro, while deferring the options to various .pri files. A bit more information, although admittedly not much more, can be found here.
The format of the .pri files is exactly the same as the format of the .pro files. The main difference is one of intent; a .pro is what most people would expect to run qmake on directly, while a .pri is to be included by a .pro. When you instruct qmake to include another file, it just processes the commands in that file as if it were in the current file.
For Reference: *.pro vs *.pri
Assume the following directory structure
project/project.pro
project/project.pri
In this case even if the project.pro file does not have a statement like (include project.pri). Does it gets included automatically by qmake.
In the qtcreator sources plugin directory
qt-creator/src/plugins/coreplugin
There is a coreplugin.pri file which is not included in the coreplugin.pro file
I'm fairly confident that it does not get included automatically, and I did a quick test with a .pro and a .pri file that had message calls in them to confirm this.
With regards to the files you're seeing in creator, it's not uncommon to have a .pri file that is designed for other .pro files to include so that you can use the project.
I'm currently transferring a project built with qmake to CMake.
In the version with qmake, in the .pri file, there was
MOC_DIR = .moc/$${PLATFORM_NAME}
that permitted to produce the MOC temporary files in a given directory, keeping the sources clean. How to do the same thing with CMake?
Note: with CMake, I use the FindQt4.cmake package and the command QT4_WRAP_CPP().
As baysmith says, if your goal is to keep your source directory clean, the real solution is to use CMake's "out-of-source" builds feature. If you're on Windows, set "Where to build the binaries" to a new directory, different from the "Where is the source code" directory. If you're on Unix, it goes something like this:
cd <source directory>
mkdir build
cd build
cmake ..
make
By running CMake on a different directory, all of the build files will go into that directory, and your sources will stay clean. (Note: the build directory doesn't have to be inside the source directory. See the CMake wiki for more details.)
If "out-of-source" doesn't work for you, I was able to find one other option. Based on what I can tell from the Qt4Macros.cmake file installed with my CMake 2.8, it isn't accessible as a config parameter. Here's the relevant line:
SET(_moc ${CMAKE_CURRENT_BINARY_DIR}/${_current_MOC})
The workaround is to change all of your MOC include directives to specify the subfolder you'd like to build to.
#include "moc/mainwindow.moc"
After creating the moc directory inside my build directory, there were no problems building, and my MOC file was in the new directory.