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.
Related
There is a issue that is present with some very specific aspect of applications I build using a Qt library provided in repositories of the system I'm using; this issue isn't present with the same numerical build of Qt that I built myself on this exact system.
I would like to query all information about build environment of Qt, it's configuration flags, etc., anything that could help me determine the difference between two build of Qt library.
I've learned about config.summary file, that is present in mine qtbase sources, but there isn't a counterpart anywhere in the system for pre-built version (I have, besides headers, installed a sources and debug information for the qt library packages).
I also tried looking for some header files that could specify, for example, what features were enabled at the build time, but could't locate anything like that (mostly because I don't know the name or some example contents of such file so that I could search for it or grep it), so if there is indeed such file, please point me to it.
I think the best reply is to quote this answer from Qt mailing list
Unfortunately it isn't that easy to figure out but the data is
available; you just need to know from where to search it :D
Configure options can be found from (qtbase) build log, from qt5.git
integration. E.g for 5.6.3
here:https://testresults.qt.io/coin/integration/qt/qt5/tasks/1505476672
and for 5.9.5 here:
https://testresults.qt.io/coin/integration/qt/qt5/tasks/1523412986
And SW details here: https://wiki.qt.io/Qt_5.6_Tools_and_Versions &
https://wiki.qt.io/Qt_5.9_Tools_and_Versions
You can find the latest builds at https://testresults.qt.io/coin/?project=qt%2Fqt5
If you look inside the "Build" section you have all the system configurations Qt is built for (column "Target") and for each configuration the parameters (column "Configure Arguments").
I've been asked to customise the layout of the GNOME 3 desktop. Apparently the way to do that is by writing an "extension".
I've managed to do some of the things I wanted to do, but I feel utterly starved of information. I cannot find any useful documentation anywhere. I've wasted entire days of my life frantically googling every imaginable search term in a desperate attempt to find useful information.
The GNOME website has hundreds of extensions for download. These are not trivial 3-liners; they're sophisticated pieces of code. It defies belief that anybody could write these without documentation explaining how to do it.
Please, can somebody tell me where the actual documentation is? So far, the best I've managed to do is take apart existing extensions trying to track down the magic command that does the specific bit I'm interested in. (Not an easy task!)
Command names, object paths, example programs, anything would be helpful!
I have recently dug into it myself. The documentation is usually sparse or outdated. Here are some sources which helped me to get started (and through development):
Basic Stuff
Step-by-step tutorial (Gnome 3.4)
Unofficial documentation for the JavaScript bindings of many libraries
The sources of the gnome-shell's JavaScript bindings
Explanation of the St (Shell Toolkit) Ui-Toolkit components.
Some unofficial guidelines to get your extension on extensions.gnome.org
Since the documentation is nearly unavailable (or up to date), you'll need to do a lot of source-reading. I linked the gnome-shell sources above (the JavaScript part) which is a good start when diving into parts that are not covered by the In-official documentation (which is the most complete thing you'll find).
What's also particular helpful is checking extensions.gnome.org for extensions which do similar things to what you want to create, and look at their sources (most of them are open-source on GitHub or Bitbucket. You can also install them and find the sources under ~/.local/share/gnome-shell/extensions/).
When searching for something to use or more documentation on a particular function, you can also consult manuals for bindings in different languages (thought the parameters and return-values might not match).
Last but not least, here is some debugging advice:
LookingGlass is not particularly helpful. It only shows one line of an exception (the description) and only if they occur at startup time (when your extension is first started).
For full StackTraces and runtime-exceptions, consult the ~/.xsession-errors-file. It might be very long and bloated. I use this handy script to read it:
# Grabs the last session-errors from the current X11 session.
# This includes full Stack-Trace of gnome-shell-extension errors.
# See https://live.gnome.org/GnomeShell/Extensions/StepByStepTutorial#lookingGlass
tail -n100 ~/.cache/gdm/session.log | less
Note that since Gnome 3.6, if you are using gdm as display manager, the current session log is the file ~/.cache/gdm/session.log.
On some newer distros using systemd, you can get the error logs with:
journalctl -f /usr/bin/gnome-session
For debugging the prefs-part of your extension, you can launch the preferences by using the gnome-shell-extension-prefs-tool from a terminal, to see any exception-output on the console (you can also call the tool like gnome-shell-extension-prefs [uuid], to directly show your extensions preferences).
Since there is currently no real way of debugging with breakpoints (there is, but it's tricky), you can log on the console for quick checking, use the print()-function. You will see the output as mentioned above (either in the sessions-error file or on the terminal when starting gnome-shell-extension-prefs-tool).
Although it might be a little hard to get into it, the extension framework is quite powerful. Have fun!
I wrote a Blog-Post with somewhat greater detail, which can be found here: Making Gnome-Shell Extensions
An extensive list of references can be found on the Gnome Developer - API Reference page.
I used the following for my extension, but your use may vary:
GTK+ 3
GTK+ is the primary library used to construct user interfaces in GNOME applications. It provides user interface controls and signal callbacks to control user interfaces.
GDK 3
GDK is an intermediate layer which isolates GTK+ from the details of the windowing system.
Clutter
Clutter is a GObject based library for creating fast, visually rich, graphical user interfaces.
GObject Introspection
GObject Introspection is striving to provide a middleware layer between (GObject based) C libraries and language bindings.
Shell
Shell Reference Manual
St
St - Shell Toolkit - is the GNOME Shell's custom Clutter-based toolkit that defines useful actors. Some of these actors, such as StBoxLayout and StBin implement various layout options.
Icon Theme Specification
This freedesktop.org specification describes a common way to store icon themes.
NOTE: These last two are very helpful in finding visual element parameters!
PyGTK
PyGTK is GTK+ for Python. This reference contains a chapter for each Python PyGTK module (that corresponds to the underlying GTK+ library) containing the class descriptions.
PyGObject
PyGObject is a Python extension module that gives clean and consistent access to the entire GNOME software platform through the use of GObject Introspection. Specifically speaking, it is Python Bindings for GLib, GObject, GIO and GTK+.
This reference contains a chapter for each PyGObject module containing the class descriptions.
The documentation is on:
https://gjs.guide/extensions/
For the documentation of libraries:
https://gjs-docs.gnome.org/
More details on https://gjs.guide/extensions/overview/architecture.html
The other stuff you might want to check are
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/popupMenu.js
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/dialog.js
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/modalDialog.js
https://gitlab.gnome.org/GNOME/gnome-shell/blob/main/js/ui/panelMenu.js
https://gitlab.gnome.org/GNOME/gnome-shell/tree/main/js
https://gitlab.gnome.org/GNOME/mutter
You can browse under js/ for more code to be reused.
You might also want to check https://gi.readthedocs.io/en/latest/index.html
Question:
I could not find anything under https://gjs-docs.gnome.org/ except some CSS and Javascript documentation ?!?!
Answer:
You have to first enable the docs to use them. Here, you will be mainly looking for:
clutter
meta
shell
st
Create a file like:
echo '{"docs":"clutter9~9_api/clutterx118~8_api/gobject20~2.66p/meta9~9_api/shell01~0.1_api/st10~1.0_api","hideIntro":"1"}' > devdocs.json
Import this file to https://gjs-docs.gnome.org/settings
Now you will be able to visit:
https://gjs-docs.gnome.org/shell01~0.1_api-global/
https://gjs-docs.gnome.org/shell01~0.1_api/
https://gjs-docs.gnome.org/meta9~9_api/
https://gjs-docs.gnome.org/st10~1.0_api/
https://gjs-docs.gnome.org/clutter9~9_api/
https://gjs-docs.gnome.org/clutter9~9_api-actor/
Warning: The version on the devdocs.json file is hardcoded. It will be outdated in no time, so you might want to check the version. The point is - you can not access docs until you enable them.
P.S. I know, this is a mess. This is how they did it.
I'm trying to deploy an application using macdeployqt. All Qt frameworks get copied correctly into the application bundle. The problem I encounter is that macdeployqt does not have write permissions on the copied frameworks which originally reside in /usr/local/lib. This is because I have installed qt using homebrew which seems to make install everything read only. My question is whether there is a better way to fix this issue then manually changing all permissions of the qt libraries inside /usr/local/lib so that I can use macdeployqt from within a qt .pro project. (I don't want to use macdeployqt manually with sudo or such)
The reason why I'm asking is because I am using many third party libraries in the project (they get copied ok etc.) which I need to update often through homebrew and thus have to redo the permission changing on them.
Thanks in advance!
Just in case someone finds this old post looking for info about macdeployqt:
Use a script to do macdeployqt in preference to scripting the macdeployqt commands in your .pro file. That will allow you to change the permissions on the files on the fly.
Here is [a snippet of] the script I use for one of my apps:
https://bugreports.qt-project.org/browse/QTBUG-23268
If you're on Windows and don't have bash, you can use perl or python. The script referenced above modifies the files on the fly to work around a bug - you can put anything you want here, including changing the permissions on the files.
Using a script also means that you have the flexibility to add commands later to do code-signing, packaging or whatever else you need.
The Qt .pro "scripting language" actually generates Makefile commands under the hood and can be quite obscure if you want to accomplish deployment tasks that relate to paths and sets of files.
Also you'll need to create an extra target or include it into your build target - either way the build process becomes more complex and more error prone.
Disclaimer: I worked on Qt for 8 years as a Senior Engineer for Nokia/Trolltech, and also have published a commercial cross-platform app using Qt.
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...
Why does every source package that uses a makefile come with a ./configure script, what does it do? As far as I can tell, it actually generates the makefile?
Is there anything that can't be done in the makefile?
configure is usually a result of the 'autoconf' system. It can generate headers, makefiles, really anything. 'Usually,' since some are hand-crafted.
The reason for these things is to allow source code to be compiled in disparate environments. There are many variations on Unix / Linux, with slightly different system headers and libraries. configure scripts allow code to auto-adapt.
The configure step is a sort of meta build. It generates the makefile that will work on the specific hardware / distribution you're running. For instance it determines the name of the C or C++ compiler and embeds that in the makefile.
The configure step will also frequently take a set of parameters, the values of which may determine what libraries need to be linked against. For instance if you compile Apache HTTP with SSL enabled it needs to link against more shared libraries than if you don't. Since linking is handled by the makefile, you need an extra step to create a custom makefile (rather than requiring the make command to require dozens or hundreds of options.
Everything can be done from within the makefile but some build systems were implemented otherwise.
I don't personally use configure files for my projects but I admit I mostly export Erlang & Python based projects.
I don't think of the makefile as a script, I think of it as an input to the make utility.
The configure script (as its name suggests) configures the makefile, including as you say resolving dependencies.
If only from the idea of avoiding self-modifying code, the things in the configure script don't really belong in the makefile.
the point is that autoconf autohdr automake form an integrated system the makes cross platform building on unix relatively str8forward. THe docs are really bad and there are lots of horrible gotchas but on the other hand there are a lot of working samples
When I first came across this stuff I thought - "ha I can do that with a nice clean makefile" and proceeded to rework the source that way. Big mistake. Learn to write and edit configure.ac and makefile.am files, you will be happy in the end
To answer your question. Configure is good for
is function foo available on this platform and if so which include and library do I need
letting the builder choose if they want feature wizzbang included in a nice simple consistent way