CPack DEB Packaging: Automate dependency resolution

Hello

Currently in my project, I provide all dependencies for DEB packaging in 
CPack by setting the variable CPACK_DEBIAN_PACKAGE_DEPENDS. Is there a 
possibility to automate this process (similar to the behavior of the 
CPack RPM packaging mechanism)?

As far as I understood it correctly, such a mechanism must be 
implemented with the Linux tool 'objdump' to get the dependencies of 
shared libraries. I already thought about implementing my own script to 
get these dependencies of my shared libraries automatically. But first, 
I wanted to make sure that I do not reinvent the wheel. Especially 
because I found the following entry in 'CPackDeb.cmake' next to the 
dependency section:  ' TODO: automate 'objdump -p | grep NEEDED'.

David

Re: CPack DEB Packaging: Automate dependency resolution

2008/11/1 David Graf <david.graf@...>:
> Hello
>
> Currently in my project, I provide all dependencies for DEB packaging in
> CPack by setting the variable CPACK_DEBIAN_PACKAGE_DEPENDS. Is there a
> possibility to automate this process (similar to the behavior of the CPack
> RPM packaging mechanism)?

Just to note that _currently_ CPack RPM does NOT handle "automatic"
dependencies.
With a pending feature request one may _MANUALLY_ add dependency:
http://public.kitware.com/Bug/view.php?id=7904

then more dependencies are set-up _AUTOMATICALLY_ by "rpmbuild"
which is the tool called by CPack RPM generator for generating RPM.
I don't even know whether if those dependencies are exhaustive or not...

To be clear, CPack RPM generator does not do _anything_ for
automatic dependencies handling.

> As far as I understood it correctly, such a mechanism must be implemented
> with the Linux tool 'objdump' to get the dependencies of shared libraries. I
> already thought about implementing my own script to get these dependencies
> of my shared libraries automatically. But first, I wanted to make sure that
> I do not reinvent the wheel. Especially because I found the following entry
> in 'CPackDeb.cmake' next to the dependency section:  ' TODO: automate
> 'objdump -p | grep NEEDED'.

I don't really know how if one can expect to find the _PACKAGE_ name
from a "NEEDED" objdump section.

Boost Trunk is getting CMake support

Just wanted to let the cmake community know that very early CMake  
support has been added to the Boost trunk. Currently only some of the  
libraries will build but there is now active development of the boost- 
cmake build system. The current support is bleeding edge and may NOT  
work at all on your system. If you want to have a look try reading the  
following wiki page for more details:

https://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild

_________________________________________________________
Mike Jackson                  mike.jackson@...
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio

Re: Bundle Generator conflicts with MACOSX_BUNDLE

Mike Arthur wrote:
> On Friday 31 October 2008 16:18:51 Timothy M. Shead wrote:
>> Of course, you still have to provide a mechanism so the executable can
>> be located when your user double-clicks your bundle.  That's where
>> CPACK_BUNDLE_STARTUP_COMMAND comes-in ... it copies a bundle-specific
>> file into the Contents/MacOS directory.  That file could be a symlink to
>> the actual executable, or a startup script.  Note that it is *never*
>> intended to be the executable itself.
> Ah, ok, this wasn't fully understood. Can you suggest how I might make this a 
> symlink? Just manually create a relative one and pass it to 
> CPACK_BUNDLE_STARTUP_COMMAND?

That's the (untested) idea - although it occurs to me that the copy
command may try to copy the symlink target instead of the link itself.

Cheers,
Tim

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake

Re: Boost Trunk is getting CMake support

On Saturday 01 November 2008 20:16:42 Michael Jackson wrote:
> Just wanted to let the cmake community know that very early CMake
> support has been added to the Boost trunk. Currently only some of the

That is great news! Occasionally I struggle to cross-compile Boost, and 
this should make it a lot easier. 

--

-- 
Kind regards, Esben

Re: Boost Trunk is getting CMake support

2008/11/2 Esben Mose Hansen <kde@...>:
> On Saturday 01 November 2008 20:16:42 Michael Jackson wrote:
>> Just wanted to let the cmake community know that very early CMake
>> support has been added to the Boost trunk. Currently only some of the
>
> That is great news! Occasionally I struggle to cross-compile Boost, and
> this should make it a lot easier.
>

I'll second that! I can cross-compile, but its never easy and I
usually dont fully understand the process.

Re: Boost Trunk is getting CMake support

Daniel Stonier wrote:

> 2008/11/2 Esben Mose Hansen <kde@...>:
>> On Saturday 01 November 2008 20:16:42 Michael Jackson wrote:
>>> Just wanted to let the cmake community know that very early CMake
>>> support has been added to the Boost trunk. Currently only some of the
>>
>> That is great news! Occasionally I struggle to cross-compile Boost, and
>> this should make it a lot easier.
>>
> 
> I'll second that! I can cross-compile, but its never easy and I
> usually dont fully understand the process.

It should be noted that:

- linux->linux cross compile with Boost.Build generally just works
- linux->windows cross support was recently completed
- windows->linux cross should be fixed by Monday
- complete documentation is coming soon

So, you don't really need CMake for that.

- Volodya

Patch for UseSWIG and question about module

I have just submitted a patch for module UseSWIG.cmake to solve some
problems with language Java.
http://public.kitware.com/Bug/view.php?id=7915

When solving these problems, I was wondering why the generated JNI
library was not installed as a runtime under Windows.
With CMake 2.6, dynamic libraries (DLL) are considered as RUNTIME and
could be separately installed into directory bin/. The import
libraries are considered as LIBRARY and are normally installed into
directory lib/.

The JNI library generated by UseSWIG is not built as a shared library
but as a module (to export all symbols if i understand well). Since
under Windows, a DLL is generated, Windows modules should be
considered as RUNTIME. Is it correct ? It would allow to install JNI
DLLs into directory bin/ like other runtimes.

J. Bedouet

Re: Boost Trunk is getting CMake support

FIXED..

Thanks for the feedback

Mike
On Nov 2, 2008, at 3:49 AM, Maik Beckmann wrote:

> 2008/11/1 Michael Jackson <mike.jackson@...>:
>
> Hi Michael,
>
>> If you want to have a look try reading the following wiki page for  
>> more
>> details:
>>
>> https://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild
>
> There the statement
> {{{
> svn co http://svn.boost.org/svn/boost $BOOST/src
> }}}
> will check out the _hole_ repository into $BOOST/src. See
> {{{
> $ svn list http://svn.boost.org/svn/boost
> branches/
> empty/
> sandbox/
> sandbox-branches/
> sandbox-tags/
> svnmanager/

Re: CPack DEB Packaging: Automate dependency resolution

Am Saturday 01 November 2008 12:44:39 schrieb David Graf:
> Currently in my project, I provide all dependencies for DEB packaging in
> CPack by setting the variable CPACK_DEBIAN_PACKAGE_DEPENDS. Is there a
> possibility to automate this process (similar to the behavior of the
> CPack RPM packaging mechanism)?
>
> As far as I understood it correctly, such a mechanism must be
> implemented with the Linux tool 'objdump' to get the dependencies of
> shared libraries. I already thought about implementing my own script to
> get these dependencies of my shared libraries automatically. But first,
> I wanted to make sure that I do not reinvent the wheel. Especially
> because I found the following entry in 'CPackDeb.cmake' next to the
> dependency section:  ' TODO: automate 'objdump -p | grep NEEDED'.

No, you would get libraries but on Debian you should use dpkg-shlibdeps 
instead (or read its manpage and do it the same).

HS