[OSGeo-Discuss] OSGeo4W maintenance activities
mohammedrashadkm at gmail.com
Sat Feb 20 22:43:09 PST 2016
On Sat, Feb 20, 2016 at 7:10 PM, Jürgen E. <jef at norbit.de> wrote:
> Hi Rashad,
> On Mon, 15. Feb 2016 at 21:56:19 +0530, Rashad Kanavath wrote:
> > Currently, due to ABI incompatibility upgrades are stuck. For instance
> > ossim.
> BTW that's the only example there is (at least AFAIK). And that's only
> OSSIM is insisting on using the GEOS C++ API that nothing else in OSGeo4W
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
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
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.
If there is a compiler selection, then user can choose mingw, maybe there
will be only grass for now...
if they choose msvc2010 then have a lot. And if they choose 2015, they will
have only gdal maybe..
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
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.
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?
> Everything else was migrated to the more stable C-ABIs to avoid having to
> support myriads of different packages to support a number of different C++
> compilers, their versions and combinations there of. IMHO that would be a
> large effort, which only marginal visible advantage to the user.
Could you get the list of all C++ packages.
Qt, OTB, OSSIM, GEOS-C++, boost, qwt, qgis ?
Current situation is any c++ library or application using Qt must be
compiled with msvc2010. Is that right?
If so, I think removing such a restriction could be very marginal to user.
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.
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.
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.
> AFAICT there's not much in OSSIM depending on GEOS. So porting might not
> too difficult. But the question about the possibility of porting OSSIM to
> the C API wasn't really answered (see
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.
> Jürgen E. Fischer norBIT GmbH Tel.
> Dipl.-Inf. (FH) Rheinstraße 13 Fax.
> Software Engineer D-26506 Norden
> QGIS release manager (PSC) Germany IRC: jef on FreeNode
> Discuss mailing list
> Discuss at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Discuss