Rainer, from my 8 years of writing open source I learned the following:
Some users understand open source. They are happy about the work already done. And if it does not fit their needs they look into the code, fix it and send a patch. Usually these patches come without big notice in advance. No lengthy discussion, no long complaining. Nothing. They simply fix their problem and donate the code. Interesting enough these patches are usually of good quality and really add function. Other users start to discuss big ideas and what they think they want to add and so on. They keep you occupied over quite some time. The outcome is usually meager. Most users simply use the software. They are happy with the compiled binaries. They read the documentation. And if that does not help they ask a question. If it's not implemented they simply accept it as a matter of fact. After all this is donated work. And it is work in progress. The situation might evolve. And then there are users with an attitude. They complain. They ask why the software does not match their expectation (always assuming their expectation is of general interest). And of course they know much better how you should have done your job. And if you refuse they blame you for wasting their precious time. Probably they would ask their money back if they ever had paid some. Luckily they disappear pretty fast after they go tired trolling around. You are welcome to pick your category. On the technical side: There is currently a pending pull request: https://bitbucket.org/maproom/qmapshack/pull-requests/80/default/diff Ivo has started to rework the application setup layer. In this pull request we had a small discussion about blocking compilation of unsupported platforms this morning. Therefore the topic will be addressed by this pull request. Bye Oliver Am 02.03.2016 um 13:33 schrieb Dr Rainer Woitok: > 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 Qlandkartegt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
