Rainer, GDAL and Proj4 compile on systems like Cygwin because someone spent the time to adjust and test these packages on the various systems. For example do a grep for CYGWIN on the source code of GDAL and you will see that there are numerous #ifdef CYGWIN together with other flavors of Windows. It is naive to think that any software with a complexity of GDAL, Proj4 or as you want QMapShack will compile and run out of the box on every system.
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. 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 can just repeat: If you think QMapShack should run on Cygwin you have to check all system dependent code sections. They are easy to find by the OS_ defines. For every define you have to analyze the code and decide if you can make use of one of the existing flavors. In that case you can widen the compiler scope. If not you have to fix the code. When done you have to test if QMapShack is still working with the new code. If it does you can send you changes via a pull request to the repository. After a review they will be part of the repository. By that you do not have to patch later versions. This is the way how all open source packages have been ported in the past. QMapShack won't be an exception. Oliver Am 29.02.2016 um 13:39 schrieb Dr Rainer Woitok: > Oliver, > > On Friday, 2016-02-26 15:30:33 +0100, you wrote: > >> ... >> The Q_ should tell you it's a Qt macro. Have a look at the Qt5 >> documentation. >> >> I do not know your motivation to compile QMapShack in a Cygwin >> environment. But if you insist, you are on your own. > I have compiled quite a few software packages in a Cygwin environment, > including GPSBabel (which uses Qt5), NetCDF, and Proj4 (the latter two > both using "cmake"), but none of these products (or their maintainers) > had problems treating Cygwin and Unix/Linux more or less the same. Thus > my problems compiling and running QMapShack on Cygwin are neither Qt nor > "cmake" related. So, to slightly rephrase your own words: I do not know > your motivation to prevent QMapShack from compiling and running in a > Cygwin environment. After all, even though Cygwin DEFINITELY IS differ- > ent from Unix/Linux, the differences are marginal, and require at most a > few additional "#ifdef" clauses in the source code, if any at all. > > Best proof is that making QMapShack run on Cygwin only required to ex- > plicitly define the "Q_OS_LINUX" macro whenever calling the C compiler. > > By the way, QMapShack will currently also fail to compile and run on > real Unix systems like, to name just a few, Solaris, HP-UX, and AIX. Is > that really what you want? Where all you initially had to do would be > to use the "cpp" standard macro "__unix__" rather than "Q_OS_LINUX" in > your handful of relevant "#ifdef" clauses? > > 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
