Within the .pro file, things are straightforward if you're including header files (use HEADERS), C++ files (use SOURCES) and Objective-C / Objective-C++ files (use OBJECTIVE_SOURCES), but it is less clear to me how other file types should be included.
e.g. looking at various examples that Qt provide, there is inconsistency about whether QML files should be DISTFILES, OTHER_FILES or contained within a .qrc file (i.e. RESOURCES). I've gone with putting QML files in a qml.qrc file.
My question has arisen because I'm including data files, such as audio .wav files, within a .qrc file (also as shown in Qt examples; e.g. Qt Quick Demo - Maroon in Trouble) but this has slowed compiling down to a crawl. And in the case of MinGW on Windows, it simply crashes with an out of memory error when it reaches 1GB. There must be a better way to include these!
Could you provide a guide as to when to use:
DISTFILES
OTHER_FILES
RESOURCES
Quoting from the qmake manual:
RESOURCES
Specifies the name of the resource collection files (qrc) for the target. [...]
DISTFILES
Specifies a list of files to be included in the dist target. This feature is supported by UnixMake specs only. [...]
OTHER_FILES
This seems in fact undocumented, at least I could not find anything. As far as I can tell all files listed here are only linked in project explorer (of Qt Creator for example) and are not treated in any way by qmake.
As for your example you might consider shipping the files as they are and not include them in any resource file, because they are compiled into the binary.
You may also take a look at compiling external resources and using them for your large files to keep the simplicity of Qt's resource system.
DISTFILES: Something special for unix you won't use in most cases. From the docs:
Specifies a list of files to be included in the dist target. This
feature is supported by UnixMake specs only.
OTHER_FILES: Files, that are part of you project, but not of the "build". This can be things like a readme, build hints, or any other stuff, that does not fit into any other categories
RESOURCES: .qrc-files, that will be compiled into the application.
Regarding the usage of those three with QML:
You can basicly use DISTFILES or OTHER_FILES for other files. In QtCreator the appear in a node as other files. These two are exchangeable for most developers. The Qt examples are local project, thus either they don't require a resource or have both, i.e. you can find the QML-files in for example OTHER_FILES and RESOURCES.
For QML files, you should always use RESOURCES, to make sure they are within your binary.
Speaking of DISTFILES , you can try it yourself.
Assuming you are using Qt on Windows. Here is a very simple qmake project file project.pro:
TEMPLATE = app
DISTFILES += "C:\Windows\explorer.exe"
qmake it, and you can find the following statements in generated Makefile.Debug and Makefile.Release:
DIST = C:\Windows\explorer.exe
...
dist:
$(ZIP) project.zip $(SOURCES) $(DIST) project.pro
...
The target dist is one of the standard targets. I learned it from makefile - What is the difference between make and make dist? - Stack Overflow.
Related
In qmake based projects, it's possible to include OTHER_FILES to use them in QtCreator, e.g.
QT += core gui widgets
TARGET = example-program
TEMPLATE = app
HEADERS = mainwindow.h
SOURCES = main.cpp mainwindow.cpp
OTHER_FILES = README.md LICENCE examples/network/server.c
That way one can access README.md within QtCreator easily. A CMake file with the same target looks like
cmake_minimum_required(VERSION 3.5)
project(example CXX)
set(CMAKE_AUTOMOC ON)
find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED)
set(HEADERS mainwindow.h)
set(SOURCES main.cpp mainwindow.cpp)
set(OTHER_FILES README.md LICENCE examples/network/server.c)
add_executable(example-program ${SOURCES} ${HEADERS})
target_link_libraries(example-program Qt5::Core Qt5::Gui Qt5::Widgets)
However, the OTHER_FILES aren't shown in QtCreator and I have to access them via "File > Open" instead of the project browser. Is there a workaround?
You can use a custom target that depends on the given files:
add_custom_target(project-related-files SOURCES ${OTHER_FILES})
Since the COMMAND is missing, an empty target will be generated, but it will still depend on the SOURCES. This is also the official way to include other files into an IDE:
SOURCES
Specify additional source files to be included in the custom target. Specified source files will be added to IDE project files for convenience in editing even if they have no build rules.
There's no problem with adding non-compiled files as the sources of a CMake target; CMake will simply ignore them if it doesn't recognise their extension. So you can easily do this:
add_executable(example-program ${SOURCES} ${HEADERS} ${OTHER_FILES})
With files which could be confused for actual sources (based on their extension), there's always the option of setting their HEADER_FILE_ONLY property to true:
set_source_files_properties(
${OTHER_FILES}
PROPERTIES
HEADER_FILE_ONLY TRUE
)
I'll comment that I think both answers are correct, which to use depends on the particulars of the project.
Angew's answer adds the files to a single project, within the project.
In my case, Zeta's answer worked better, as I had files at the top-level of a project with subprojects, and having a new folder (with a name I could customize) in QtCreator better fit my needs.
Adding an additional answer, as I didn't see the differences between the two approaches mentioned.
I have a library called qml_components containing basic QML graphical elements. I'd like to add these files to the project tree, without building them. I've been able to regroup them in a variable, by doing the following:
CMAKE_MINIMUM_REQUIRED(VERSION 3.4)
CMAKE_POLICY(SET CMP0003 NEW)
PROJECT(myApp)
FILE(GLOB QML_SRC "*.qml")
I then tried to add them to my library target:
# Add QML files to project tree without building/compiling them
ADD_CUSTOM_TARGET(myApp ${QML_SRC})
While researching I read that ADD_CUSTOM_TARGET could add the files to the sources without building them:
The SOURCES option specifies additional source files to be included in the custom target. Specified source files will be added to IDE project files for convenience in editing even if they have not build rules.
It doesn't seem to work. I think the probable cause is that I do not generate any binaries from this library, hence the failure when trying to link the sources to the TARGET.
I had forgotten to add the SOURCES keyword in the command...
ADD_CUSTOM_TARGET(myApp SOURCES ${QML_SRC})
I'm leaving this thread open as it could be of useful information to others.
It is a known bug that moc trips over macros used in libstdc++ as documented here: http://lists.kde.org/?l=necessitas-devel&m=132317657926916&q=raw
I am trying to compile a project which uses gcc 4.6.3 and am stuck because moc trips over the macros.
One way to overcome the problem is to include the directives as mentioned in this link:
http://doc.qt.io/qt-4.8/moc.html
but that is time consuming and not a very clean way as every file has to have these directives.
What I'd like to know is, can qmake be configured such as to make moc skip certain directories/files?
edited: typos
According to the Qt qmake docs moc will be run for files that are added to the HEADERS variable (emphasis mine):
qmake will generate dependency information (unless -nodepend is specified on the command line) for the specified headers. qmake will also automatically detect if moc is required by the classes in these headers, and add the appropriate dependencies and files to the project for generating and linking the moc files.
So if you don't want moc to be run for certain files then don't add them to the HEADERS in your .pro file. However, for some platforms that might cause the headers not to be found when compiling the corresponding .cpp files. To fix that, add an INCLUDEPATH for the folders containing such headers - moc won't be run for headers that are inside an INCLUDEPATH.
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