Currently, I have a file which contains some version tagging information which is used by the .pro file and parsed by qmake, but the problem is that when that file changes qmake is not re-run.
Is it possible to add something to the .pro file so that qmake will treat this file as a dependency for the Makefile?
Sometheing like this should work:
depend_on_file.target = depend_on_file
depend_on_file.depends = path_to_your_txt_file
depend_on_file.CONFIG += recursive
QMAKE_EXTRA_TARGETS += depend_on_file
PRE_TARGETDEPS += depend_on_file
Rebuild will be triggered if file path_to_your_txt_file changes but keep in mind that if your qmake script that parses the file changes DEFINES variable then you out of luck. Defines are not listed in dependencies, you see. If defines are changed you have to do full rebuild by hand.
Related
Let's talk about it in linux terms. I have a ".so" file. I want to make the executable dependent on it, look for it in the same directory. How do you do it through qmake? Or can this only be achieved through the use of QLibrary?
For example, when you have a ".so" file and want to use it in your project, in qmake you write:
LIBS += -L"path to the folder that contains your .so" -lSoName
But the path is hardcoded, as you can see, and I'm wondering what to write there to make the executable look for the ".so" in the same directory.
You use RPATH
You can configure your binary or library to find shared library (or dll) in current directory using RPATH directive that is emedded in the binary itself which the loader respects at runtime
1- Add the following in your .pro file
unix {
message("Adding RPATH to the app")
QMAKE_LFLAGS += -Wl,-rpath=\'\$$ORIGIN/\'
QMAKE_RPATH =
}
This will set RPATH of executable to current directory and your executable will first try to look for that .so in your current directory and then in standard directory (this process is explained here)
2- After you compile and create binary VERIFY that RPATH is set correctly
objdump -x <path/to/binary> |grep RPATH
it should say $ORIGIN
Compile time configuration:
CXXFLAGS += -L"/path/to/libmarylin.so/file" -lmarylin
There are a few ways to do it.
If the executable is going in the current directory, just do LIBS += -L$$(PWD) -lSoName.
If you're putting the executable into some other sub-directory, specified by some qmake variable like DESTDIR, use LIBS += -L$$(DESTDIR) (or whatever variable holds that directory).
Alternatively, you can add the directory with the executable to the runtime path of the executable, which gives the dynamic linker a list of directories to search for any unresolved libraries at runtime. This can be done with QMAKE_RPATHDIR += -L$$(PWD) and LIBS += -lSoName, which will tell the linker to look for unresolved libraries in the current directory where qmake is run.
Some operating systems may also include the current directory in the runtime search path for libraries by default, in which case just doing LIBS += -lSoName should be sufficient. That is platform-dependent, though, while the above solutions are not.
I would like to add a custom command, that will work on the generated binary file (The target field in *.pro file),
But what should I use here, in the Command arguments
I'm afraid this is not possible. QtCreator only handles source and build directory. The QtCreator documentation says:
The following Qt Creator variables are available:
%{buildDir}
%{sourceDir}
Note that the target even doesn't have to be in the build directory. The build directory is where qmake is ran, typically resulting in the target being put there, because in the .pro file one typically specifies TARGET = projectName.
Further note that the QtCreator build steps configuration only works within QtCreator. This should not be used when your custom build steps are needed for other people working without QtCreator (they should only run qmake and make to build your application).
This being said and assuming that you want to define a post-build step, you should look for a solution to define such in the .pro file (by using the $${TARGET} variable) so that qmake will put your buildstep into the Makefile after the linking step.
If you want to execute a command after linkage, let's say call a custom script (batch script on Windows, otherwise a bourne shell script) with the TARGET as an argument, add the following to your .pro file:
win32 {
poststep.commands = #myScript.bat $${TARGET}
}
!win32 {
poststep.commands = #./myScript.sh $${TARGET}
}
QMAKE_EXTRA_TARGETS += poststep
I have a project that uses Qt. So I have "qmake" make my Makefile from the .pro file. But Qmake can also make that .pro file: qmake -project . This worked until I needed to add an external extra library to my project.
I get lots of hits on google that tell me to add LIBS += ... to my project file, but I want to tell qmake -project something that causes it to add it for me. In effect of course I'll be doing it myself, but I don't think that it's proper that I am editing the generated project file.
If for example I add files to the project directory, I'll have to recreate it and add in the library again, or I'll have to manually add the files to the (almost completely computer-generated) project file. I'm now using a script to auto-generate the project file, and then add in the LIBS += directive, but is there a proper way to do this?
When you are developing without the Qt Creator IDE, unless the IDE includes by itself some automatic utilities, you must edit manually the .pro configuration file.
The generated .pro file is a skeleton file which YOU must fill in with the libraries that you need, then the qmake system figures out the other dependencies and compiles your project. It is a essentially a much better version of pkg-config of gtk + Makefiles.
When you add more source and resource files to your project then manually you must add them to the .pro file.
Example:
QT += core gui
TARGET = qtcp1
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp \
miwidget1.cpp \
lcdrange.cpp
HEADERS += mainwindow.h \
miwidget1.h \
lcdrange.h
FORMS += mainwindow.u
Alternately, you can issue qmake -project over and over again, but this can cause some unforseen accidents, since it includes everything that is in the current directory at the time, including the pre-processed files for conversion to standard C++ from QT dialect. This intermediate files must be erased (cleaned), before the remaking the project and the next make or can lead to tricky problems.
Using the official and free QT Creator IDE takes away most of this burden by adding automatically the new data to the .pro file and cleaning loose ends. Some other IDEs like Code::BLocks and Codelite provide some facilities for QT, but not to the level of QT creator. Some prefer to edit the .pro themselves for custom reasons, other like more other styles of IDEs, like Eclipse.
You should test the waters and decide by yourself what fits best to your needs.
ReEdited, to clarify a few things.
I have a Qt project with a german translation, Translation_de.ts, which is automatically compiled into Translation_de.qm via Qmake:
TRANSLATIONS += Translation_de.ts
...
QMAKE_EXTRA_COMPILERS += lrelease
lrelease.input = TRANSLATIONS
lrelease.output = ${QMAKE_FILE_BASE}.qm
lrelease.commands = $$[QT_INSTALL_BINS]/lrelease ${QMAKE_FILE_IN} -qm ${QMAKE_FILE_BASE}.qm
lrelease.CONFIG += no_link target_predeps
The generated Translation_de.qm is then compiled into the final application as a resource:
RESOURCES += Resources.qrc
where Resources.qrc looks like this:
<RCC>
<qresource>
...
<file>Translation_de.qm</file>
</qresource>
</RCC>
All of this works fine, except that the very first call to Qmake on a fresh checkout throws the following annoying warning:
RCC: Error in 'Resources.qrc': Cannot find file 'Translation_de.qm'
What am I doing wrong here? How do I correctly specify an auto-generated resource file like Translation_de.qm?
http://doc.qt.io/qt-5/qmake-variable-reference.html
CONFIG+=lrelease #generates *.qm files from TRANSLATIONS= to the directory builddir/.qm/
CONFIG+=embed_translations #adds them as qrc resources
so (other than)
CONFIG+=lrelease embed_translations
no qmake magic is required. Your qm files will be under :/i18n/ unless you specify otherwise with
QM_FILES_RESOURCE_PREFIX=/my/customtranslationdirectory
Create the generated files in qmake phase with e.g. system(lrelease...). Leave the other rules in place too so you don't have to rerun qmake when the input files are changed.
I think that what you want is just "ignore_no_exist" for lrelease.CONFIG
As far as I know the target_predeps ensures that it is executed before the 'normal' compilation steps are issued. So if it's really only about getting rid of the warning, just add the above given flag. Your qm creation should work once you execute the makefile that was created by the qmake call.
If your qm files are not created try to add:
PRE_TARGETDEPS += compiler_lrelease_make_all
Check out this link for more options that might help you.
We have a fairly large code-base. The vast majority of the code is compiled using qmake to produce the makefiles. However, there are some sub-projects that get produced by running batch files or running other programs.
I'd like to be able to have everything compiled using qmake, but I can't figure out how to get qmake to simply run a script.
One thing that I've tried is using QMAKE_EXTRA_TARGETS in my pro file, like so:
TEMPLATE = lib
SOURCES = placeholder.cpp
CONFIG += no_link staticlib
batch_runner.target = placeholder.cpp
batch_runner.commands = my_batch_file.bat
QMAKE_EXTRA_TARGETS = batch_runner
I then have to have the batch file produce placeholder.cpp like so:
# do the real work here
# ...
# create placeholder.cpp so qmake and nmake are happy
echo // dummy >> placeholder.cpp
This seems to work fine. The trouble is that it is somewhat hokey. If I don't specify batch_runner.target (i.e. I leave it blank) or don't put placeholder.cpp in SOURCES then the batch file never gets run. This is because qmake isn't making batch_runner.commands the action for any other dependency in the Makefile.
Is there any better way to get QMake to construct a Makefile such that a script is run when the Makefile executes?
It looks like QMAKE_POST_LINK works well for this sort of thing.
This seems to get the job done. my_batch_file.bat runs when nmake runs (rather than when qmake runs) and I don't need to do anything funny with placeholder targets or files.
It's quite likely that I don't need all of the items listed in 'CONFIG'.
TEMPLATE = lib
TARGET =
CONFIG += no_link target_predeps staticlib
QMAKE_POST_LINK = my_batch_file.bat
QMAKE_CLEAN += batch_output.obj
Try the system() command. For example:
system(pwd)
Here is another solution:
TEMPLATE = aux
OBJECTS_DIR = ./
DESTDIR = ./
first.commands = my_batch_file.bat
QMAKE_EXTRA_TARGETS += first
QMAKE_CLEAN += batch_output.obj
The template aux basically produces a makefile which does nothing when run without specifying a target. The OBJECTS_DIR and DESTDIR variables are set to the current directory to prevent that qmake creates the debug and release directories (it's important to set them to ./ and not just to .; at least on Windows). Then, using QMAKE_EXTRA_TARGETS, we redefine the target first to run the custom command when the makefile is invoked without target.
It's a bit hacky but it gets the job done.
Addition:
If you want to prevent the generation of three makefiles (Makefile, Makefile.Debug, Makefile.Release), you can add
CONFIG -= debug_and_release
However, if you use this and depending on how the makefile is invoked (always invoked manually, invoked by parent directory's "subdirs" *.pro file, ...), it might be necessary to create fake debug and release targets to avoid "no rule to make target..." errors. For example:
release.target = release
release-clean.target = release-clean
release-install.target = release-install
[...]
debug.target = debug
debug-clean.target = debug-clean
debug-install.target = debug-install
[...]
QMAKE_EXTRA_TARGETS += release release-clean release-install [...]
QMAKE_EXTRA_TARGETS += debug debug-clean debug-install [...]
You could use the SUBDIRS configuration to run multiple different targets, even from the same makefile. This might work especially well with your extra targets, as a subdir configuration can specific a specific target in the makefile to run (see undocumented qmake for details). In this case, I would put all of the "regular" build commands in one .pro file, the external build commands in another, and a subdirs .pro file to build all of them. I haven't tested anything quite like this, but it should work.
regular.pro:
SOURCES += main.cpp
TARGET = regular.exe
external.pro:
batch_runner.commands = my_batch_file.bat
QMAKE_EXTRA_TARGETS += batch_runner
other_runner.commands = other_batch_file.bat
QMAKE_EXTRA_TARGETS += other_runner
do_it_all.pro:
TEMPLATE = subdirs
CONFIG += ordered
regular.file = regular.pro
SUBDIRS += regular
batch.file = external.pro
batch.target = batch_runner
SUBDIRS += batch
other.file = external.pro
other.target = other_runner
SUBDIRS += other