Oliver,
On Monday, 2016-02-29 15:17:08 +0100, you wrote:
> ...
> Therefore it's best practice to limit system specific patches only to
> those systems tested. There is a good chance that QMapShack will run on
> other *unix based systems, like the ones you listed. But as long as no
> one is trying and testing the stuff it would be careless to widen the
> scope of the system specific code.
Please let me summarize our discussion up to this point:
1. I build QMapShack from a freshly cloned source repository. The com-
pilation completes without any errors, but the binary segfaults im-
mediately when run.
2. I (incorrectly) assume that this has to do with Qt5 not finding a
"styles/" directory and contact the QMapShack mailing list for help,
specifying "Cygwin" in the mail's subject line. The product main-
tainer (correctly) assumes that this has nothing to do with Qt5, and
even though he realizes I'm on Cygwin (because he immediately puts
Cygwin on a level with Windows) he doesn't tell me that QMapShack is
not expected to run on Cygwin at all, but rather just asks me to re-
compile with the debug option and to produce a backtrace.
3. I produce and send the backtrace, the maintainer looks at it and at
his code, diagnoses a bug, and promises a fix. He hints that this
might perhaps not solve the Cygwin problem but does not consult the
relevant Qt documentation (to which he will refer me later) just to
make sure.
4. From his diagnosing I assume that nobody yet has run QMapShack on
Cygwin, and am told that on Windows (again!) QMapShack has to be com-
piled using VisualStudio, that the Windows community doesn't seem to
care about QMapShack, and that I'll have to fix "everything MinGW
related" by myself. I'm slowly getting the impression of a rather
hefty misconception or prejudice regarding Cygwin.
5. The patch announced initializes an unititialized pointer to "nullptr"
(which surely makes the code more reliable) but doesn't solve my pro-
blem at all, because (since the operating system is neither recogniz-
ed as MacOS, Linux, nor Windows) the patched routine still doesn't
return a pointer to some structure, but now returns "nullptr" rather
than just an unititialized pointer, causing the program to immediate-
ly segfault again.
6. I then recompile QMapShack one more time, this time simply telling
"cmake" explicitly to create Linux code, and I get a working binary
that way. Reporting this success back to the list I am only frowned
at and am told again that I am on my own.
7. Nobody (repeat: 0 developers) ever asks me to run "make run_tests",
"make qttest", or "make qttest_automoc" (the only make targets listed
by "make help" that contain the string "test") and to report the out-
come.
And now you are telling me in all earnest that it's good practice to
prevent a software from being tested by causing it to immediately seg-
fault on operating systems on which "no one is trying and testing the
stuff". How should that ever work? How to test a segfaulting binary?
Don't you trust your test suite or don't you trust Cygwin at all?
I'd like to offer the following patch. Mind that this is neither irony
nor cynism, but rather an attempt to prevent others from wasting so much
time to learn that QMapShack (at least currently) only wants to run on
MacOS, Linux, and native Windows.
The first "#if" clause produces a clean compilation error, if the oper-
ating system doesn't fit, because in my oppinion a segmentation fault is
always a programmer's error and can never be interpreted as a hint that
people "are on their own", should they insist to continue.
The second "#if" clause simple prevents some dead code.
diff --git a/src/helpers/CAppSetup.cpp b/src/helpers/CAppSetup.cpp
--- a/src/helpers/CAppSetup.cpp
+++ b/src/helpers/CAppSetup.cpp
@@ -37,14 +37,14 @@
{
if(nullptr == instance)
{
-#ifdef Q_OS_MAC
+#if defined Q_OS_MAC
instance = new CAppSetupMac();
-#endif
-#ifdef Q_OS_LINUX
+#elif defined Q_OS_LINUX
instance = new CAppSetupLinux();
-#endif
-#ifdef Q_OS_WIN32
+#elif defined Q_OS_WIN32
instance = new CAppSetupWin();
+#else
+#error "Unsupported OS. Please contact the QMapShack mailing list."
#endif
}
return instance;
@@ -205,6 +205,7 @@
}
+#if defined Q_OS_MAC
CAppSetupMac::CAppSetupMac()
{
}
@@ -265,6 +266,7 @@
}
+#elif defined Q_OS_LINUX
CAppSetupLinux::CAppSetupLinux()
{
}
@@ -290,6 +292,7 @@
}
+#elif defined Q_OS_WIN32
CAppSetupWin::CAppSetupWin()
{
}
@@ -340,3 +343,4 @@
//reset PATH to avoid that wrong .dll's are loaded
qputenv("PATH", "");
}
+#endif
> Anyway, the GPS device support of QMapShack is completely system
> dependent. The Linux version relies on DBus and UDisk2. These aren't
> available on all *nix based systems. That is probably the trickiest part
> to fix.
I've already noted that my QMapShack issues a warning message during in-
itialization regarding DBus and UDisk2. But this, at least currently,
is of no importance to me, because I start with GPX files, and because I
have GPSBabel installed which is able to connect to, say, my old GPS V.
But I'll also keep an eye on these drivers when testing.
There are, however, other topics I've already noticed which may or may
not have to do with Cygwin or my very personal environment, and I will
report on them to this list as time permits.
Sincerely,
Rainer
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Qlandkartegt-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
