Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance: add qmake project files #5

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

SlySven
Copy link

@SlySven SlySven commented Jun 28, 2020

The project that I wish to use GdbCrashHandler in provides both qmake and cmake build systems so we need qmake project files as well. This PR attempts to provide them.

It was necessary to modify the header inclusion for the QuaZip library for the ./lib/GdbCrashHandlerDialog.cpp file, it seems that Debian Linux, at least, puts it in a quazip sub-directory.

I also note that this library is at version 0.3.0 and that is what I specified in the QMake project file - so it buils the chain of symbolic-
links to the un-versioned libGdbCrashHandler.so using those numbers. However the Cmake project file produces version numbers based on a 1.0.0 semantic version number - I guess one of these is not right but it isn't precisely clear yet why a sub-unity version number is being used to produce a unity product version.

Signed-off-by: Stephen Lyons [email protected]

The project that I wish to use GdbCrashHandler in provides both qmake and
cmake build systems so we need qmake project files as well. This PR
attempts to provide them.

It was necessary to modify the header inclusion for the QuaZip library for
the `./lib/GdbCrashHandlerDialog.cpp` file, it seems that Debian Linux, at
least, puts it in a `quazip` sub-directory.

I also note that this library is at version 0.3.0 and that is what I
specified in the QMake project file - so it build the chain of symbolic-
links to the un-versioned `libGdbCrashHandler.so` using those numbers.
However the Cmake project file produces version numbers based on a 1.0.0
semantic version number - I guess one of these is not right but it isn't
precisely clear yet why a sub-unity version number is being used to produce
a unity product version.

Signed-off-by: Stephen Lyons <[email protected]>
@@ -30,7 +30,7 @@
#include <QTimer>
#include <QUrlQuery>
#include <QUuid>
#include <quazipfile.h>
#include <quazip/quazipfile.h>
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't work as a general upstream solution, i.e. other distros use quazip5/quazipfile.h. The proper way is for quazip-devel to ship a CMake module and/or pkg-config file which returns the include path. On Fedora, FindQuaZip5.cmake does this, but quazip does not seem to provide a pkg-config file (which is the typical way to include dependencies with qmake). You'll need to explicitly pass the include dir via QMAKE_CFLAGS env-var when building the project, or patch it locally.

@manisandro
Copy link
Owner

The so version is unrelated to the project version number, it's just a three digit sequence according to https://semver.org/.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants