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
signature.asc
Description: Digital signature
_______________________________________________ Discuss mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/discuss
