[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: repacking ossim source code in git.





On Wed, Jan 6, 2016 at 9:37 PM, Sebastiaan Couwenberg <sebastic@xs4all.nl> 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


Refreshing patches is common step as part of the procedure to update the
packaging for a new upstream release. Because ossim packaging requires
special care, we need to better document in debian/README.source and
noting the need to update in the patch description is a good idea too.

>>> Last point,
>>> The patch to ossim/CMakeLists.txt seems inappropriate to me. Do we need
>> to
>>> provide both static and shared in the single package ?
>>
>> I don't know why it was added, you should ask frankie who added it. I
>> kept these changes because it was added for a reason, and didn't want to
>> make drastic changes to the ossim package which I only updated to fix
>> some bugs for 1.8.16, and recently to update it to 1.8.20 to assist the
>> OSGeo-Live effort which uses the packaging too.
>>
>
> All it does is creating a static library called ossimstatic. But this was
> not installed in a separate .install files and IIRC, the build seems to
> ignore it. It gives me libossim.a instead of libossimstatic.a

The static library has been included in libossim-dev since 1.8.16-1, and
it's still installed:

 $ grep libossim.a debian/*install
 debian/libossim-dev.install:usr/lib/libossim.a

libossim-dev also includes the shared library libossim.so, having only
the extension differ between the shared & static library is the common
convention.

> Maybe a static ossim might be required for some other debian packages.

otb is the first package to use ossim, there are no packages in the
archive that use ossim. OSGeo-Live does have other project that require
ossim.

> If package must give both static and shared libs, should we add another
> package libossimstatic  in debian/control to keep it clean ?

No, the .so symlink and the .a library should stay together in the -dev
package.

https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952

> 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


Kind Regards,

Bas

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




--
Regards,
   Rashad

Reply to: