In a C++/Qt project, we are using .pro-files and qmake to build. Part of the project is a static lib. The .pro file goes like this:
TEMPLATE = lib
CONFIG = staticlib
#general build instructions
linux{
#some os-specific build instructions
}
win32|win64{
#some os-specific build instructions
}
However, these scopes are never entered, not on a linux system (when the first scope should execute), nor on a windows system (for the second scope).
This only appears to be a problem in the staticlib-configuration/lib-template.
The Qt-documentation mentions the different templates, but I do not see anything mentioned as to why scopes would not work or how to solve this.
Those conditions are true if they're set in the CONFIG variable. By overwriting CONFIG with staticlib, you reset all preset flags, including the ones specifying the platform.
It should work if you do CONFIG += staticlib
Related
I have a project where the library sources were set up the following way:
MyProject
|_MyProject.pro
|_MainStuff
|_MainStuff.pro
|_ManyFiles
|_Tests
|_Tests.pro
|_LotsOfTests
|_MyLibs
| FunLibs.pro
|_FunLib1.h
|_FunLib1.cpp
|_FunLib2.h
|_FunLib2.cpp
This is not ideal, because as the number of FunLibs increases, all of it would be included into a single shared object. With this setup, everything builds and runs just fine. Just to be clear: MyProject.pro is a subdirs template, the MainStuff.pro is an app template, and the FunLibs is a lib template.
The problem stats, when I rearrange the files the following way:
MyProject
|_MainStuff
|_ ManyFiles
|_Tests
|_LotsOfTests
|_MyLibs
|_MyLibs.pro
|_FunLib1
|_FunLib1.pro
|_FunLib1.h
|_FunLib1.cpp
|_FunLib2
|_FunLib2.pro
|_FunLib2.h
|_FunLib2.cpp
Here the MyLibs.pro becomes a subdir tempalte, while the FunLibx.pro files will be lib templates. All configurations have been updated accordingly and the application builds. The problem is that when I now try to launch the application, the following message pops up:
libFunLib1.so.1: cannot open shared object file: No such file or
directory
I don't really understand why doesn't it work now, when it worked with the previous directory structure. This post for example (as many others) recommends to set the LD_LIBRARY_PATH by exporting the dir, but to be honest, I didn't have to do this with the previous setup.
I also have everything set up pretty much as described in the official docs under the "Creating a shared library" part.
Does anybody have an idea what might be the problem? Is there a way to solve this by not exporting the path?
Thanks in advance.
OK, I think I found out what can fix the aforementioned problem. Qt Creator also uses LD_LIBRARY_PATH environment variable for executing compiled programs, but it is somewhat hidden. As it turns out, it is able to use separate sets of env variables for compiling and running applications, and if the env vars for running are not properly defined, the user will get the error message mentioned in the original post, even if the program compiled properly.
To make sure all lib paths are included for running as well, one needs to check out the included paths here:
Projects (mode) --> Run Settings (under Build & Run) --> Run
Environment (expand the Details) --> LD_LIBRARY_PATH (somewhere in the
list)
If that var doesn't include the proper paths, it can be edited after which it is going to get highlighted. After setting this, everything seems to work.
I am building a program in QT that is going to need a user definable run configuration file, similar to .vimrc. In short, it will need to define what keypresses are responsible for basic commands in a curses like interface.
I have not quite decided what format to use, but thought that QBS might suit the bill as I am already using it for project management, and it would seem that on the surface that it would be well suited for this sort of thing.
The idea is to have the configuration file sitting in /home/me/.programrc, which is easy enough. I do not know however what interpreters exist for its syntax in Qt or C++, if any, or whether it is practically suited to serve as a run configuration in the first place.
Is this whole idea conceptualized properly, and do adequate tools exist for achieving this goal?
Thanks.
QBS is now deprecated in favor of CMake (along with QMake).
You can add a ".qmake.conf" file in the same dir where you .pro file resides.
In this file you can store parameters which you can use in .pro/.pri files.
.qmake.conf
BUILD_DIR=$$shadowed($$PWD)/build
BUILD_TESTS_DIR=$$shadowed($$PWD)/unit_tests
SCRIPTS_DIR=$$PWD/scripts
TOP_SRC_DIR=$$PWD
project.pro
DESTDIR = $$BUILD_DIR/
INCLUDEPATH += $$TOP_SRC_DIR/
You could add your keypress confiog in the DEFINES parameter, e.g. for TOP_SRC_DIR:
DEFINES += "TOP_SRC_DIR=\\\"$$TOP_SRC_DIR\\\""
TOP_SRC_DIR is now known in your source code as a define.
Of course you will need to rebuild the file(s) which use the define so you may bind the define(s) to centralized "extern" variable(s) which you link to and force re-linking when the parameters change (e.g. PRE_TARGETDEPS += $BUILD_DIR/myParams.a)
I'm trying to set the OUT_PWD parameter when using Qt Creator. The documentation say's NOT to overwrite this parameter. So, is there another safe way to change this parameter in the .pro file?
The reason I want to modify this directory is to maintain a uniform workspace across all of my developers. At the moment when a person opens a new project, they need to ensure the "build directory" is set correctly in the "project" tab. I'd like to make this a parameter that is set in the .pro file so that all developers are working in the same directory structure.
This is important as I have both Apps and Libs combined in a SUBDIRS type of project and need to ensure the Libs end up in the right place.
Thanks for any help you can provide.
This makes zero sense, because the build folder is meant to be arbitrary, and you're meant to have possibly a multitude of build folders for any given project - depending on how you build the project.
I think that your workflow is broken, and the fix is to the workflow itself, not to project files.
This is important as I have both Apps and Libs combined in a SUBDIRS type of project and need to ensure the Libs end up in the right place.
That's done by adding targets that put the executables/libraries where you want them, not by modifying OUT_PWD.
The solution I used was the following.
Debug:DESTDIR = $$PWD/debug
Debug:OBJECTS_DIR = $$PWD/debug/.obj
Debug:MOC_DIR = $$PWD/debug/.moc
Debug:RCC_DIR = $$PWD/debug/.rcc
Debug:UI_DIR = $$PWD/debug/.ui
Release:DESTDIR = $$PWD/release
Release:OBJECTS_DIR = $$PWD/release/.obj
Release:MOC_DIR = $$PWD/release/.moc
Release:RCC_DIR = $$PWD/release/.rcc
Release:UI_DIR = $$PWD/release/.ui
The build directory is still placed in whatever location is specified by the .pro.user file (which is not something I was concerned with), but at least the lib files are placed in a known location relative to the .pro file and will therefore be uniform across my developers.
I found part of the solution at this link (How to specify different Debug/Release output directories in QMake .pro file), but the main difference is the addition of $$PWD/ to the beginning of the path
What is the correct way of defining cross platform behavior in qmake? I'm attempting to merge two projects that use the same codebase but have different parameters in the qmake project file for things like different compiler flags or icon files.
To clarify, if someone pulls the MyProject.pro from version control and attempts to run qmake on it on a mac, I want a couple lines to change when compared to the same operation on a windows machine. Is there any way of adding arguments to $> qmake ... or better, not have to change anything?
Yes, QMake does support conditional statements, in the form of scopes. Basically, you write something like this:
DEFINES = MY_DEF
win32 {
DEFINES += WE_ARE_ON_WINDOWS
debug {
DEFINES += DEBUG_WINDOWS
}
}
As the example shows, scopes can be nested. Operators such as | for OR are also possible.
For a full list of variables and functions, refer to QMake documentation.
You can write something like:
win32:{
# Do something Windows specific
} else {
# Options for other platforms
}
in your .pro file(s).
In short, I want to change the type of application to win32 app, then, I've used the following commands in .pro file
CONFIG -=windows
QMAKE_LFLAGS += $$QMAKE_LFLAGS_WINDOWS
After use the previous commands the application works fine as I want.
But the problem is I don't know what the meaning of each command of these commands.
Can anybody explain each command of these commands?
Let's see CONFIG -= windows.
Excerpt from qmake manual: CONFIG variable
CONFIG
The CONFIG variable specifies project configuration and compiler
options. The values will be recognized internally by qmake and have
special meaning. They are as follows.
[...]
The following options define the application/library type:
windows - The target is a Win32 window application (app only). The
proper include paths, compiler flags and libraries will automatically
be added to the project.
console - The target is a Win32 console application (app only). The
proper include paths, compiler flags and libraries will automatically
be added to the project.
Another excerpt from the manual: Operators
Operators
In many project files, the assignment (=) and append (+=) operators
can be used to include all the information about a project. The
typical pattern of use is to assign a list of values to a variable,
and append more values depending on the result of various tests. Since
qmake defines certain variables using default values, it is sometimes
necessary to use the removal (-=) operator to filter out values that
are not required.
The -= operator removes a value from the list of values in a variable:
DEFINES -= USE_MY_STUFF
The above line removes USE_MY_STUFF from the list of pre-processor
defines to be put in the generated Makefile.
So with CONFIG -= windows you are removing the value windows from the list of values in variable CONFIG. Looks like windows is among the default values of CONFIG on your platform and you need to remove that value. The value windows defines that your target is a Win32 window application. By removing it you declare that you would not like to have a Win32 window app. If your target is a Win32 console application instead then it is recommended to declare it explicitly: CONFIG += console.
And now let's see QMAKE_LFLAGS += $$QMAKE_LFLAGS_WINDOWS.
Excerpt from the manual: QMAKE_LFLAGS
QMAKE_LFLAGS
This variable contains a general set of flags that are passed to the
linker. If you need to change the flags used for a particular platform
or type of project, use one of the specialized variables for that
purpose instead of this variable.
[...]
QMAKE_LFLAGS_WINDOWS
This is used on Windows only.
This variable contains link flags when building Windows GUI projects
(i.e. non-console applications). The value of this variable is
typically handled by qmake or qmake.conf and rarely needs to be
modified.
This means that if you would like to change the flags then you should change either QMAKE_LFLAGS_CONSOLE or QMAKE_LFLAGS_WINDOWS. However you changed QMAKE_LFLAGS directly by adding the value of QMAKE_LFLAGS_WINDOWS which is strange because it contains link flags for building Win32 window apps and you declared with CONFIG -= windows that you would not like to have a Win32 window app.
CONFIG tells qmake that you're building for a specific platform, QMAKE_LFLAGS specifies which platform specific libraries you need.