Long story short, we have a Qt project that I'm thinking of migrating to CMake. However, some of our customers use the existing library as a subproject in a Qt subdirs project. Does that mean we are stuck with Qt for the build system?
This is possible, but ugly. You could for instance use the system() function in a qmake file:
system(command[, mode])
You can use this variant of the system function to obtain stdout from the command and assign it to a variable.
For example:
UNAME = $$system(uname -s)
contains( UNAME, [lL]inux ):message( This looks like Linux ($$UNAME) to me )
As discussed in the comment, your fallback option would be to maintain both for your project, and give your customer a reasonable amount of notice period for qmake so that they have enough time for the migration if they are willing to.
Otherwise, running the desired cmake and build commands with the system() function looks, at least one, way to go.
Related
I am using find_package to find Qt and adding "C:\Qt\5.15.0\mingw81_64\lib\cmake" to my CMAKE_PREFIX_PATH environment variable and it has worked fine when just using 64-bit up until now. However, I want the ability to switch between 32-bit and 64-bit builds. I therefore also added the equivalent above path for 32-bit, however this resulted in linking errors (presumably CMake wasn't sure which one to pick and picked the wrong one for one of the configurations).
What is the conventional way to fix this situation? At the moment I'm using a suffix path and searching in that dependent on the compiler architecture, however ideally I'd like to leave that stuff out of the CMake project itself and simply require users of the project to add whatever Qt location themselves, while still being able to have "more than one" Qt location.
Is this solvable? Or is it malpractice to have two Qt paths in your CMAKE_PREFIX_PATH variable?
What is the conventional way to fix this situation?
Only add to your CMAKE_PREFIX_PATH the Qt path corresponding to the architecture you want.
[...] however ideally I'd like to leave that stuff out of the CMake project itself and simply require users of the project to add whatever Qt location themselves, while still being able to have "more than one" Qt location.
You may request the users to pass the Qt path as a parameter (when calling CMake through the command line)
cmake -DQT_PATH={PATH TO QT} ...
Or read an environment variable (which the user would have to set)
if(DEFINED ENV{QT_ENVIRON})
set(QT_PATH $ENV{QT_ENVIRON})
else()
set(QT_PATH ...)
endif()
I am trying to setup a CMake project which consists of multiple static libraries and one main executable which has dependencies on QT. I would like to be able to select either a MinGW or a MSVC build when I run the cmake build.
I recently learned that the QT specific parts of CMake will find the installed library binaries for QT automatically if QTDIR is set as an environment variable and if QTDIR/bin is in the PATH.
Now I am wondering how I can set this information dynamically depending on the compiler that I am using. Since I would need to point cmake to either one of C:\Qt\5.3\mingw482_32 or C:\Qt\5.3\msvc2013_64, or possibly others if I extend the list of targets in the future.
Note that I do not need to build both compiler targets at the same time, I would usually select on target in my IDE and build that one, but I would like to be able to switch between both targets.
The solution should be in such a way, that on Linux the CMake build will still find the libraries which are installed through the package manager automatically.
Can I easily achieve this with CMake?
As a side note, in the future I might also need to select the QT version on demand? So an extensible solution would be nice.
I just want to use qmake as pro-files parser for extracting project variables (like SOURCES), nothing more. I don't need to generate makefiles.
In other similar tools "dry run" mode usually presents. I.e. "just taste this thing, but do nothing with it".
Unfortunately qmake don't have such mode, but can i emulate it with some, probably ugly||hacky way?
Now i'm trying to remove all "generation"-code from qmake source, but it is hard and long task. And i'm like simple decisions :)
The simplest way is to give the -E option to qmake. It will dump the contents of the project variables and continue without generating the makefile.
It is equivalent to the code snippet given in previous edition of this post, but dumps all of the variables and requires no changes to qmake :)
We would like to use scons for building on Windows, mainly because of its caching facilities (we use ccache on Linux, and compiliation is considerably faster there). However, all our projects are defined in qmake .pro files. The way building now works, is that we call qmake to generate a Makefile, which we then use to build with jom. Having .pro files on a high level is quite practical, so we would like to keep that and not replace the .pro files by SConfigure files. So ideally we would have qmake generate a SConfigure file, the same way it generates a Makefile now, and then run scons on that SConfigure file. Is there something out there that can do that, maybe some generator for qmake? Or is it somehow possible to convert the Makefile created by qmake into an SConfigure file?
(I'm aware that the functionality of scons and qmake overlap, for instance the dependency generation and that it would likely be better to use just scons by itself, however, qmake works quite well for Qt projects and can also generate visual studio files, so we would like to keep it.)
They are not very happy with meta meta makes. However, as suggested in that rejected merge request, something might be possible off-source using QMAKE_SUBSTITUTES, but that is a practically undocumented feature.
Or you could go the way I tried and tinker with the code directly. Have a look at https://qt.gitorious.org/~phresnel/qt/add-some-qmake-to-autotools-glue , or more specifically the diff at https://qt.gitorious.org/qt/qt/merge_requests/1040 . The file qmake/generators/special/filelist.cpp does most of the work.
Imho, it is really a pity that extension of qmake is not easier; the greater flexibility of CMake was also the reason why I switched to it, completely abandoning my use of qmake.
I have a large software project which uses aspects of OpenGL for visualisation. I want to add a GUI and was thinking of using QT. Now from what I understand, building QT stuff can get ugly unless one sticks to using the qmake command...
However, my project relies on the GNU tools for building (g++, autoconf, automake, etc., etc.). Must I therefore restructure my whole build process to use qmake just so that I can use a few small aspects of QT? I am very reluctant to do so given the size of the project.
As a thought, could I possibly (somehow) use qmake for the graphical components (i.e. qt-dependent stuff) only and continue to use my standard GNU build process (make, g++ etc.) for everything else?
Thanks,
Ben.
A quick Google search turned up AutoTroll and a howto.
Personally, I have used Qt without qmake before, but it was for a personal project, so I just used a (non-portable) Makefile. I set a variable (QT4DIR, since QTDIR was used by Qt3) to point to where I installed Qt, then added -L$(QT4DIR)/lib -lQtCore -lQtGui, etc. to LDFLAGS and -I$(QT4DIR)/include/QtCore, -I$(QT4DIR)/include/QtGui, etc. to CXXFLAGS. It looks like those links explain how to do something similar for autotools.
Edit:
To handle the MOC, I've added implicit rules like:
moc_%.cc: %.h
$(MOC) $< -o $#
And then make sure that all required moc_*.cc files are included in my SOURCES. It's a bit of a pain to specify QObject-derived classes twice, but everything will get built.
After much head-scratching, I decided to compile the original code into a library using my original build process (but slightly modified to compile a library rather than a binary) and then compile the gui separately using qmake. This would then also link the gui in with the original library code. Not 100% ideal but works fine. Probably the biggest hurdle was converting some glut code into a QGLWidget...