<div dir="ltr">Hello Jurgen,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 20, 2016 at 7:10 PM, Jürgen E. <span dir="ltr"><<a href="mailto:jef@norbit.de" target="_blank">jef@norbit.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rashad,<br>
<span class=""><br>
On Mon, 15. Feb 2016 at 21:56:19 +0530, Rashad Kanavath wrote:<br>
> Currently, due to ABI incompatibility upgrades are stuck. For instance<br>
> ossim.<br>
<br>
</span>BTW that's the only example there is (at least AFAIK). And that's only because<br>
OSSIM is insisting on using the GEOS C++ API that nothing else in OSGeo4W needs<br>
anymore.<br></blockquote><div> </div><div>one is enough for an example. I agree on the ABI stability issue and usage of C api if available and I do think that OSSIM should switch to Geos C API. This is good for not only osgeo4W but also for debian and other linux distro packages.<br></div><div><br></div><div>OSGeo4W is a packaging effort. It is a windows package installer which should be able to handle these issues. I know you were saying user won't care if asked to select a compiler when running osgeo4w-setup<arch>.exe. And it is a lot of effort to maintain different compiler and its arch version for setting up packages. Well if all turns out good, I think it will pay off in terms of user satisfaction of osgeo4w.</div><div><br></div><div>Apart from ossim issue, There is mixing of mingw (grass, IIRC) and msvc dlls in osgeo4w installation. A user does know nothing about these situation. As you know mixing dlls like these can be dangerous and is one of the reasons, I can't use cmake 3.0 or higher with any osgeo4w package.</div><div><br></div><div>If there is a compiler selection, then user can choose mingw, maybe there will be only grass for now...</div><div><br></div><div>if they choose msvc2010 then have a lot. And if they choose 2015, they will have only gdal maybe..</div><div><br></div><div>I understand your argument that someone needs to create so many package for osgeo4w and none will be giving it to osgeo4w. Well, This is wrong. At least history says so.. There is ossim package only because otb needs ossim. same for opencv and itk, I guess. So nobody will upload those packages is incorrect. AFAICT, ossim, itk, opencv are built using msvc2010 is only because osgeo4w sticks to that version. All of these compile nicely on MSVC2015.</div><div><br></div><div>For any C library, geos-c api, gdal C api etc.. the libs can be reused in other version of compiler. So they are available irrespective of the selected compiler version. Only those with c++ will be missing depending on the package vendor or the decision of upstream developers.</div><div><br></div><div>Also if the choose mingw, grass will be there along with all the C API ed libraries that are compiled on msvc for now. And who knows in future grass developers will be setting up a mingw build for osgeo4w?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Everything else was migrated to the more stable C-ABIs to avoid having to<br>
support myriads of different packages to support a number of different C++<br>
compilers, their versions and combinations there of. IMHO that would be a<br>
large effort, which only marginal visible advantage to the user.<br></blockquote><div><br></div><div><br>Could you get the list of all C++ packages.</div><div><br></div><div>Qt, OTB, OSSIM, GEOS-C++, boost, qwt, qgis ?<br></div><div><br></div><div>Current situation is any c++ library or application using Qt must be compiled with msvc2010. Is that right?</div><div><br></div><div>If so, I think removing such a restriction could be very marginal to user.</div><div><br></div><div>BTW, it can't be so sure that none of the packagers that depends on qt would provide a new binary for Qt5 with msvc2013 or 2015. More or less the same story of opencv, ossim packages.</div><div><br></div><div>In Linux distros, they fix a compiler to each version. This could be another way of packaging. osgeo4w X.Y version uses so and so compiler.</div><div><br></div><div>So a user downloading osgeo4w 5.0 might be use a fixed version of msvc of gcc compiler. Again no of packages a version have will vary.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
AFAICT there's not much in OSSIM depending on GEOS. So porting might not be<br>
too difficult. But the question about the possibility of porting OSSIM to<br>
the C API wasn't really answered (see<br>
<a href="https://trac.osgeo.org/osgeo4w/ticket/473" rel="noreferrer" target="_blank">https://trac.osgeo.org/osgeo4w/ticket/473</a>).<br></blockquote><div>see the 4th comment. I had talked with them in the past. Don't know if situation is changed. You should create a new ticket on ossim tracker.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
Jürgen<br>
<br>
--<br>
Jürgen E. Fischer norBIT GmbH Tel. <a href="tel:%2B49-4931-918175-31" value="+49493191817531">+49-4931-918175-31</a><br>
Dipl.-Inf. (FH) Rheinstraße 13 Fax. <a href="tel:%2B49-4931-918175-50" value="+49493191817550">+49-4931-918175-50</a><br>
Software Engineer D-26506 Norden <a href="http://www.norbit.de" rel="noreferrer" target="_blank">http://www.norbit.de</a><br>
QGIS release manager (PSC) Germany IRC: jef on FreeNode<br>
</font></span><br>_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br> Rashad</font></div></div>
</div></div>