create a geos-c++ package

[rashadkm]

the current geos package is only provide C API.

ossim requires geos c++ api.

[jef]

Can ossim be ported to the C-API?

[rashadkm]

recalling the discussion on geos-devel list;

geos c++ api is fully supported and can be used if the project wants to. So ossim is using it without any violation. It is not a serious bug is ossim that it uses geos c++. Why should the package upgrade be blocked because of ossim using geos c api. If there comes a problem because of geos-c++ api, the other packages must be given a clear documentation somewhere in osgeo4w page or atleast even try to cope with the issue. Not the other way around. Only to include a package in osgeo4w, the upstream should rewrite a part of its code which is working and is not a violation of anything that osgeo4w stands for.

Imagine if ossim someday decides to move to geos c api. the there comes otb that uses ossim c++ api. And unfortunately, there is no C api for ossim. So the packaging blocked.

Is the osgeo4w packages are specific to C projects. I never know. I am completely lost on this point. All I get was a humble request to move to c api?

[jef]

No, you just got a question you didn't answer.

[rashadkm]

The question is asked before(on ther mailing list) and answer was and is "No". Last time, I checked with ossim developers some time ago (1.8.18) and they said No. "If geos c++ api is no longer available . They will move to C API"

Now questions to you.

Q: Why should the package upgrade be blocked because of ossim using geos c api. ?

Q: Is using goesc++ api in ossim by any means a violation in osgeo4w ?

Q: Can you provide a detailed explaination why geos c++ api is not included while geos-devs says it is supported and is legal to use it. ?

[jef]

Replying to rashadkm:

The question is asked before(on ther mailing list) and answer was and is "No". Last time, I checked with ossim developers some time ago (1.8.18) and they said No. "If geos c++ api is no longer available . They will move to C API"

Fair enough - although I was more looking for something between "yes, we're using GEOS in a single file and what we need is also in the C API" and "no, what we need isn't covered by the C-API or we use GEOS C++ all over the place and could only port with huge effort".

Q: Why should the package upgrade be blocked because of ossim using geos c api. ?

I thought OSSIM wasn't using the C++ API!?

Q: Is using goesc++ api in ossim by any means a violation in osgeo4w ?

How could it? OSGeo4W is a package repository - not a ruleset you can violate.

Q: Can you provide a detailed explaination why geos c++ api is not included while geos-devs says it is supported and is legal to use it. ?

Because using the C++ ABI virtually can break on every update - even if the compiler isn't switched. You're also tied to using the same compiler in the dependent package that was used to build the dependency (image something using Qt (C++) API and GEOS C++ API - if the two dependencies are built using different compilers - anything using both is screwed). Using the C API doesn't create that kind of interdependency - that's probably why the C API is recommended.

And that's probably also why we've put some effort into porting stuff using C++ APIs to using the C-APIs (GDAL uses GEOS C-API, QGIS uses GEOS C API and GDAL C-API although they also have C++ APIs). So we didn't need the GEOS C-API anymore in OSGeo4W.

[rashadkm]

Okay. Thanks for detailed explanation. That is a clear answer.

Let us imagine that we port ossim geos c++ part to c api. And there comes otb that uses ossim. so the problem comes back when ossim is compiled with a different compiler and and otb or something is using a new one.

Is it possible to isolate these stuff in seperate directories in the server.

msvc2010/{x86,x64}/ossim,geos,otb,qt, msvc2013/{x86,x64}/ossim,geos,otb,qt

Users can choose between different osgeo4W installers depending on the version of compiler. This also allows to chime in mingw toolchain. So there is no need to mix msvc and mingw dll as in the case of grass.

If msvc2013 or 2015 have not much packages... then that is not a problem. It will arrive later.

Users can always to choose to stick with any version of msvc and developers can decide to support any compiler and its arch(x86/x64) if they want.

osgeo4w becomes more friendly with other compilers or toolchain or c or c++ api. It does not leave a burden on developers or packagers to must support all versions. It is upto the upstream to decide wheather to provide it or not.

Users are also free to get latest compiler and other related stuff by this way.

This org must be on the server and not on the local system. It should install always on C:/OSGeo4W/{usr,lib,share}

It make osgeo4w more friendly in setting up development environment for Windows. Like the upstream can provide an eclipse/visual studio sln file. with the -dev or like in the windows terms an SDK

[jef]

Replying to rashadkm:

Let us imagine that we port ossim geos c++ part to c api. And there comes otb that uses ossim. so the problem comes back when ossim is compiled with a different compiler and and otb or something is using a new one.

Sure. ossim should be built with the same compiler as otb - if it want's to be available for otb (w/o providing a C-API). And AFAIK otb is already using Qt (which also doesn't provide a C API) - so everything there is already tied to msvc2010 (which is what Qt was built with).

Is it possible to isolate these stuff in seperate directories in the server.

msvc2010/{x86,x64}/ossim,geos,otb,qt, msvc2013/{x86,x64}/ossim,geos,otb,qt

Um, who's going to produce all those packages?

Users can choose between different osgeo4W installers depending on the version of compiler.

Users probably don't care about the compiler versions.

This also allows to chime in mingw toolchain. So there is no need to mix msvc and mingw dll as in the case of grass.

If msvc2013 or 2015 have not much packages... then that is not a problem. It will arrive later. ...

Sorry I don't follow.

[rashadkm]

Replying to jef:

Replying to rashadkm:

Let us imagine that we port ossim geos c++ part to c api. And there comes otb that uses ossim. so the problem comes back when ossim is compiled with a different compiler and and otb or something is using a new one.

Sure. ossim should be built with the same compiler as otb - if it want's to be available for otb (w/o providing a C-API). And AFAIK otb is already using Qt (which also doesn't provide a C API) - so everything there is already tied to msvc2010 (which is what Qt was built with).

Is it possible to isolate these stuff in seperate directories in the server.

msvc2010/{x86,x64}/ossim,geos,otb,qt, msvc2013/{x86,x64}/ossim,geos,otb,qt

Um, who's going to produce all those packages?

Same packagers who are uploading packages now. Except that there is an option to produce binaries for specific compilers.

Users can choose between different osgeo4W installers depending on the version of compiler.

Users probably don't care about the compiler versions.

This also allows to chime in mingw toolchain. So there is no need to mix msvc and mingw dll as in the case of grass.

If msvc2013 or 2015 have not much packages... then that is not a problem. It will arrive later. ...

Sorry I don't follow.

I was saying if not all packages are not available for msvc2013 or something else. That can be rebuild from the existing package source. Right ?

[jef]

Replying to rashadkm:

Replying to jef:

Is it possible to isolate these stuff in seperate directories in the server.

msvc2010/{x86,x64}/ossim,geos,otb,qt, msvc2013/{x86,x64}/ossim,geos,otb,qt

Um, who's going to produce all those packages?

Same packagers who are uploading packages now. Except that there is an option to produce binaries for specific compilers.

That could already be done by embedding the compiler version into the package name, which would also be required to manage the dependencies. But it's doesn't seem worthwhile to me. What's the gain? OSGeo4W is mainly to make applications available to the users, which probably wouldn't see the benefit of being able to choose from builds from myriads of compilers either (why stop with 2013?).

If msvc2013 or 2015 have not much packages... then that is not a problem. It will arrive later. ...

Sorry I don't follow.

I was saying if not all packages are not available for msvc2013 or something else. That can be rebuild from the existing package source. Right ?

Packages are built manually - at least there currently is no requirement to upload sources in some standardized way to make the automated production of packages possible - let alone for multiple compiler versions.