[OSGeo-Discuss] OSGeo4W maintenance activities

Sun Feb 21 06:35:52 PST 2016

Hi Rashad,

On Sun, 21. Feb 2016 at 12:13:09 +0530, Rashad Kanavath wrote:
> one is enough for an example.

Sure, but not mentioning that it's the only one, might produce a wrong
impression ;)

> 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.

Ah, ok.  I didn't gain that impression from the earlier discussion.  What does
it take to get there?

> 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.

But again only for very specific development things (ie. NSIS packages; just
because CMake implies that it can use dumpbin on all linked DLLs, when it's
using MSVC to build - which is wrong in our case).

And that IMHO is also important to mention to give a true impression.  We are
using cmake 3 in QGIS just fine.  But we're not using CPack to build NSIS
installers, but produce them from OSGeo4W packages.

Anyway, GRASS isn't buildable with MSVC.  That's out of my hands.  The
alternative to mixing DLLs would be to build everything with MinGW.  That
wouldn't help in your case either, would it?

> If there is a compiler selection, then user can choose mingw, maybe there
> will be only grass for now...

People usually pick the application they want to use and not the compiler it
was made with.  At least IMHO that's what OSGeo4W is mainly about - shipping
applications and not libraries.

> 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..

Well, my original motivation to switching from using my own builds of libraries
needed for QGIS to using libraries from OSGeo4W and also moving QGIS there, was
that I expected that projects would contribute and maintain their share - and
so I could save time.  That was wrong.

Early after I joined there was still Frank Warmerdam who did a lot - but that
got less over time.  Matt Wilkie did some work on python.  And Martin Landa
took over GRASS.  Except for some people on-and-off that's about it - the rest
mostly ended up here.

My initial move didn't really pay off - and thinking about it, I'm not really
sure that I'm better off now ;)

> 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.

I think everything also compile with newer versions - that's not the problem.
It just means you have to rebuild everything - including existing stuff - with
newer compilers. Unless you stick to C APIs, then you can build OSSIM with
whatever you want and still use the libraries built with other compilers
(including MinGW - although that needs some extra effort - see mklibs in
GRASS).

Some things however are useless without C++ (eg. Qt) and tie us to one compiler
- or a huge number of packages.  So I choose to stick with one compiler for
stuff I added for QGIS that uses C++ API (like Qt, PyQt, qwt).

Simply because don't see any reason to produce QGIS packages with a variety of
compilers and in turn no benefit in producing any for dependencies - of which
QGIS couldn't use just one anyway.

> 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.

Again IMHO OSGeo4W is for users and not for "upstream" developers.  This might
explain a lot about where I'm coming from.

The development libraries inside are just there to support other OSGeo4W
packages - not to support a wide variety of "upstream" setups.

> 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?

Of course that is a bit cumbersome - but it works.  And if the GRASS people
ever lose interest, I probably will pick it up again (unless QGIS looses
interest in GRASS - which I don't see either).

But as "well" as earlier: When I did the 64bit build, I added the then current
GRASS 6.4.3 to it and everyone was left with that until recently, when Martin
picked up the 64bit build - earlier he was only doing 32bit builds (although
everything else was already in place for 64bit).

So GRASS support won't be as good as it currently is, but still a little bit
better than much of the other stuff in OSGeo4W 32bit that is essentially
orphaned, if it isn't related to QGIS (like mapserver).  For that reason it
also didn't find their way to 64bit.

> > 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?

Yes, at least that's the safe choice.  Not all C++ libraries depend on each
other so theoretically you could add new libraries built with newer compilers -
without causing harm - but you could not mix those with C++ libraries built
with other compilern in applications.  So using an other compiler would limit
it's usability within OSGeo4W.

> If so, I think removing such a restriction could be very marginal to user.

Yes, that's that point.  Users probably won't notice a difference at all - so
why care in the first place?

> 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.

That should be done in a way not interfering with existing packages.  And
should be discussed in osgeo4w-dev (like most of this post anyway).

But for QGIS3 (maybe even 2.16; so within the next four month) I'll add Qt5 and
Python3 and in the process also switch to a current compiler.  And then I'll
probably also use that compiler for updates of other packages - although I
don't need to for those which (we) only offer a C-API.  Before, a switch would
just mean extra effort with little to no gain (for application users).

Jürgen

-- 
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden             http://www.norbit.de
QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode                         
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20160221/15092cf9/attachment-0002.sig>