Re: repacking ossim source code in git.

On Wed, Jan 6, 2016 at 10:26 PM, Sebastiaan Couwenberg <sebastic@xs4all.nl> wrote:

On 06-01-16 22:11, Rashad Kanavath wrote:
> On Wed, Jan 6, 2016 at 9:37 PM, Sebastiaan Couwenberg wrote:
>> On 06-01-16 20:59, Rashad Kanavath wrote:
>>> Okay. If picking only required is making things complex. I can update the
>>> cmake patch. But they must be updated with every release even though the
>>> patch can be applied without rejects. Moreover, cmake patch would never
>> get
>>> into upstream and I thought that add burden of package maintainers.
>>
>> I'd would like to see separate (tarball) releases of the various ossim
>> components, and have each include the build system needed for it. That
>> would make packaging much easier, especially if each component has
>> proper licensing & copyright information in its files. That's the
>> biggest problem with all the currently excluded ossim source.
>>
>
> Indeed that will be best. I think next release can have a single archive
> just for ossim-core including the cmakeModules.
> I will ask to create a release archive on github. There each component is a
> new repository. https://github.com/ossimlabs/ossim.

Exactly, since the repos are separate already, have each publish
releases too.

>>> I would prefer not to keep static and shared in same package if asked. ;)
>>
>> Why?
>
> the current macro OSSIM_LINK_LIBRARY is not working. I am not getting
> ossimstatic.a. This maybe related to other updates. ossim added such macros
> on the early days of cmake where there was not much features. Now static vs
> shared library is based on BUILD_SHARED_LIBS. So keeping this value 'on'
> and trying for static and shared is strange. It may create more problems
> than solution.
>
> Right now in case of OTB, there is a missing symbol in ossim when I pushed
> packages to ubuntu. I have libossim.so and libossim.a (not
> libossimstatic.a) So the find_library(ossim) call may get messed up. This
> may also depending on cmake version and stuff in ubuntu versions and
> debian. I haven't checked everywhere.
>
> If static and shared library must be built. It must be handled like in
> geos(cmake) or zlib. They specifically call add_library() with STATIC
> argument. Not like in ossim where a macro is used.
>
> Here the macro does not behaves exactly what the documentation or example
> says[1] . See the usage of TYPE argument. which is not used in the macro.
>
> So the two macro calls in ossim/CMakeLists.txt[2] is doing some stuff which
> I guess is surely valid for ossim 1.8.16 or lower but not for current
> release.
>
> So far, I had got only these to support my point that keeping static and
> shared in same package is not good. Maybe for other projects such as geos
> but not for ossim because it is not the clean way.
> [1]
> https://anonscm.debian.org/cgit/pkg-grass/ossim.git/tree/debian/patches/cmake#n2993
> [2]
> https://anonscm.debian.org/cgit/pkg-grass/ossim.git/tree/debian/patches/cmake#n3256

We seem to be talking about different packages, because the shared &
static library belong in the same Debian package, but may be not so much
in the same CMake package.

I was talking about the cmake patch to get both static and shared. And the recent problem in otb packages.

In CMake, it is either shared or static for most of the projects.

Some projects makes both explicitly.

I don't know if anyone uses the ossim static library, changes are good
that nobody does. But we can't really know that for sure. We can drop
the static library and see if anyone reports it as a bug.

Kind Regards,

Bas

--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

Regards,
Rashad