I am evaluating the feasibility of converting my app (Win32) to Qt. I would like to convert the code so that I can gradually convert one single codebase from Windows GDI to Qt, rather than cloning the source and have duplicate code. By flipping one global switch, or declaring one manifest constant in the project properties, I want to convert and test, while being able to release a production version (with the old code) whenever necessary.
Windows starts with a WinMain() function, I see that Qt has a main().
Is there an technique to organize the source to facilitate this? What is the best way to structure the code?
If "how to facilitate this" means "how to change Windows executable entry point" then
in VS project settings: "Configuration Properties > Linker > Advanced" put in "Entry Point" this "mainCRTStartup".
If you need to do that from command line then check this: Replacing WinMain() with main() function in Win32 programs
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 looking for a way to create a minimal static build of Qt 5.1. By minimal, I mean a build with only the basic set of widget classes available (including 2D graphics acceleration through an OpenGL canvas/widget). I am aiming for a static build on Windows 7 32-bit using MinGW-builds GCC 4.8.1 as well as their bundle of MSYS and tools.
I have downloaded the entire source tree, and have met some problems with compiling due to the dependency of packages such as OpenSSL and ICU (the latest OpenSSL did not compile). I wanted to see, if I could avoid dependencies of these packages and, at the same time, achieve a minimal static build of Qt 5.1 so my final executable is not gigantic in size.
I took a look at this list:
http://download.qt-project.org/official_releases/qt/5.1/5.1.0/submodules/.
Q1: Which of these modules, do I need to select to have a basic Qt build without all the fancy stuff?
Q2: Are these modules interdependent on each other in some way (I assume they are all dependent on "qtbase")?
Q3: Do I use the names from that list, (for example: "qtxmlpatterns", "qtx11extras", "qtwebkit", etc.), to deselect them in the configuration of my Qt build?
It would also be nice, with an explanation of the various submodules of Qt 5? If someone could point to any links or docs with illuminating words on this subject, that would also be great.
I shared this same goal. I wanted to "minify" Qt, building only a small subset of the libraries/DLL(s) and omitting the rest.
I did succeed, at least on Mac OS X. I assume that this approach will work on other platforms, too.
I thought that the trick would be to find some kind of exclusion flags for the "configure" script, but that turned out not to be the case.
Here is what I did:
Download the source distribution (in my case, qt-everywhere-opensource-src-5.1.1). of course, extract it all.
Edit the following three "pro" files. these files are in a qt-specific format (but plain text). They are platform-independent project files that Qt (via qmake) uses to generate makefiles.
qtbase/src/src.pro
qtbase/src/plugins/plugins.pro
qtbase/examples/examples.pro
All the changes that I made to the "pro" files were deletions. I deleted references to: dbus, ipc, network, qtconcurrent, sql, xml, sqldrivers, qdbusxml2cpp, qdbuscpp2xml, src_dbus, src_concurrent, src_sql, src_network.
That last part may sound scary. It really wasn't.
The pro files contain a list of module names, plugin names, and directory names. It seemed fairly straightforward how to delete (for example) all SQL-related lines.
Step 3.
The usual configure/make/install. However, note the "module-qtbase" argument passed to make:
./configure -prefix ~/my_test_dir/
make -j2 module-qtbase
make -j2 module-qtbase-install_subtargets
Success. This built and installed only the essentials (QtCore, QtGui, QtOpenGL, QtWidgets) and skipped all the supporting dylibs like QtConcurrent, QtMultimedia, QtSql, and QtWebKit.
ICU can link statically, and you can customize it (see docs) to reduce size. By default the data is also large, I don't know how much data you need. You could include only enough data to run in one language.
Only part of an answer.
There's no need to disable Qt modules. Each application that uses Qt decides what modules it uses and links with. A basic console-only application may use the core module only. That's what you'd use when creating, say, a web service in Qt.
I am working on an simple c++ application for my work that needs to run both on Windows and on Linux. When running on Windows it should display a simple GUI and when running on Linux it should use a textual UI (because the Linux computer don't use any GUI at all).
I was wondering if I could use Qt to write the app (since its cross platform) and replace the GUI usage on Linux with printouts to STDOUT using "#ifndef WIN32"?
Any other suggestions would be appreciated. The program reads some properties from an xml file and runs some tests according to those properties (access sockets, environmental vars etc.). My goal is to write a single project that would be statically compiled (to get an undependable executable) for each platform and avoid creating different projects.
Thank you.
It's certainly possible, but try to avoid #ifdefs as much as possible.
One approach is to isolate all the core features (data processing, networking etc...) in non-GUI classes. Then you write two sets of classes for presentation: one based on QWidgets, the other one that just does text input/output.
To wrap it up, use an #ifdef in you main() to select which "presentation" classes to use (and switch between QCoreApplication for non-GUI and QApplication for GUI).
Don't base that #ifdef on WIN32, use a custom variable. That way you can run and test both versions in the environment you're more familiar with.
I have multiple installations of Qt4 on my Windows XP SP2 machine and have installed Qt Creator 2.1 today. However, running the project (.pro) files spawns the oldest version of Qt Designer installed (the one installed in 2009 together with the rest of the framework).
Since
I would not like to remove any previous installations of Qt
and for some obscure reason even if I explicitly ask Windows Explorer to always use the version I need it does not
I would like to give up a bit and just sript the needed behaviour in a .bat file like:
e:\path\to\qtcreator.exe %1
This opens Qt Creator, but something seems to prevent it from treating the .pro file properly (in short, the project does not "open" as it should).
Qt documents have a page on the matter at Qt Creator: Using Command Line Options, but it seems to ignore the topic in question.
Since Qt (being as excellent framework as it is) is also known to have its quirks (like that of qmake), I wonder, may be there is an undocumented way to solve my problem?
(Another way to fix the thing would of course be to make the correct version of Qt Designer run, but frankly I'd prefer the "hard-wired" solution since the mechanisms provided by Qt itself are still a bit unreliable.)
The libraries and tools used for a particular project (and a configuration in it) is set in the Projects panel in Qt Creator:
http://doc.qt.io/qtcreator/creator-build-settings.html
Selecting the Qt version to use with a project should force it to run the Designer that's part of the version. If it doesn't, then you should report it as a bug.
I come from UNIX world, I'm quite familiar with Linux, Solaris, Cygwin
and MinGW development. Recently I ported one of my
big projects (cppcms) to support MSVC,
including building static and dynamic libraries with CMake.
And I get all the time absolutely weird issues:
I had CMake build issues because Windows programming
lacks naming convention
for import and static libraries.
Now I discovered that I should use different versions of ICU (debug/release builds) according to the
actual build I do (Debug/RelWithDebInfo -- should use Debug ICU, Release release ICU) and so I should
change actual conventions for searching libraries according to debug/release mode only under MSVC.
Otherwise application just would not start giving a error on missing DLL.
I don't have any such issues under Mingw or Cygwin with GCC, Open Solaris with Sun Studio or Linux with gcc or intel compilers.
And I still have numerous wired issues and wired bugs and very strange behavior -- even some trivial things do not work
under MSVC builds, when everything works absolutely fine under Solaris/Linux/Cygwin/Mingw using GCC from 3.4 up to 4.4,
Sun Studio and Intel compilers). But not under MSVC.
To be honest, I have no idea how to deal with Last one! Because it looks like for me more like environment issues.
I know that the question is not really well defined. I think I'm quite experienced
developer and I know how to write portable and good C++ code. But using Microsoft native
tools drives me crazy with issues I just don't know how to solve.
Question: What should experienced Unix programmer with quite good base in Win32 API should know when it
starts using Genuine Microsoft Tools?
P.S.: Can someone explain why "Release With Debug Info" requires Debug version of MSVC runtime? And why there two versions of runtime exist at all?
P.P.S.: Please note I don't have issues with Win32 API, in fact Windows GCC build works absolutely fine.
Clarifications:
I'm looking for pitfalls that programmer that come from Unix world would may fall into.
For example, when moving from Linux to Solaris: make sure you compile code with -mt or
-pthreads when using multi threaded programs, linking with -lpthread is not enough.
P.S.: Can someone explain why "Release
With Debug Info" requires Debug
version of MSVC runtime?
It doesn't.
And why there
two versions of runtime exist at all?
Because the debug version does more error checking.
And I still have numerous wired issues
and wired bugs and very strange
behavior -- even some trivial things
do not work under MSVC builds,
* What am I doing wrong?
Not telling us what "wired issues and wired bugs and very strange behavior" you get.
* Where should I start?
By telling us the specific errors and problems you encounter.
* What do I miss?
Reading the documentation and learning the tools.
If your question is "What do I read to become a good Windows programmer?" then my answer is: Everything from Jeff Richter, as a start.
There is no magic bullet which will automatically make you an experienced Windows developer. Windows is a very different land compared to Unix. There are lots of quirks, weird behavior, and stuff which is just plain different. The only way to get out with your sanity intact is to tackle the transition one small problem at a time. Concentrate on a specific problem and try to understand the problem. Don't just "get it to work", but really understand what is happening. A good book about Windows programming will help.
There are huge amounts of Windows knowledge and experience accumulated in the SO community, but the only way to access it is to ask concrete questions about specific problems.
The release and debug versions of DLL's use different ways of allocating memory, that is why it is not advisable to mix release and debug versions. If you allocate something in a debug mode DLL and pass it back to the application which was compiled in release mode you may get into trouble.
In the case of your naming issues you may want to have different directories where you place your static / dll's. You can do do this in visual studio by using the configuration manager, not sure how it is under the express version.
I think you need to try and actually understand the new toolset rather than just try and squish it into your current understanding of your existing tools. For that, the best way, IMHO, is for you to try and start to use Visual Studio as Microsoft intended and then once you can build a simple project in the IDE you can move to building it using your preferred make system but do so with an understanding of how the IDE is using its make system to set things up for that build (which WILL work).
So, for example, for part 1 of your question you want to create a simple static library project and a simple dll project and look at the linker options tabs. Jump to the 'Command line' view and you'll see that a DLL uses the /OUT linker option to set the name and location of the dll file and the /LIB linker option to set the name and location of the import library. With a static library only the /OUT option is used and it indicates the name of the static lib. It's true that if you're building a static lib and a DLL from the same source and you have both the /LIB for the dll set to MyCrossPlatformCode.lib and /OUT set to MyCrossPlatformCode.dll then you may have problems if you also build a static lib with an /OUT switch of MyCrossPlatformCode.lib... Simply don't do that; either build the static libs to a different output directory (which is what OpenSSL does), or, better (IMHO), mangle the names somewhat so that you have MyCrossPlatformCode.lib/.dll and MyCrossPlatformCode_static.lib (which is what STLPort does).
Note that you might also want to mangle in (or account for) building with different versions of the Microsoft tool chain (so you might end up with stlport_vc8_x64d_static.5.1, perhaps).
An alternative approach, if you really can't face the thought of understanding your toolset, is that you could take a look at some of the popular open source systems that build quite fine on Windows and Unix systems; OpenSSL and STLPort for a start, perhaps.