[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] building RTT and OCL debian packages
From:       peter () thesourceworks ! com (Peter Soetens)
Date:       2009-11-20 10:03:55
Message-ID: 634c78ce0911200203j103c4753m481abb4903010696 () mail ! gmail ! com
[Download RAW message or body]

On Fri, Nov 20, 2009 at 10:47, Steven Kauffmann
<steven.kauffmann at gmail.com> wrote:
> On Fri, Nov 20, 2009 at 9:52 AM, Peter Soetens <peter at thesourceworks.com> wrote:
>> On Fri, Nov 20, 2009 at 09:13, Steven Kauffmann
>> <steven.kauffmann at gmail.com> wrote:
>>> On Thu, Nov 19, 2009 at 1:14 PM, Peter Soetens <peter at thesourceworks.com> wrote:
>>>> On Thu, Nov 19, 2009 at 12:25, Steven Kauffmann
>>>> <steven.kauffmann at gmail.com> wrote:
>>>>> On Thu, Nov 19, 2009 at 10:57 AM, Peter Soetens
>>>>> <peter at thesourceworks.com> wrote:
>>>>>> On Thu, Nov 19, 2009 at 09:24, Steven Kauffmann
>>>>>> <steven.kauffmann at gmail.com> wrote:
>>>>>>> When installing the generated OCL debian packages, package
>>>>>>> orocos-ocl-gnulinux1.10 depends on
>>>>>>> liborocos-ocl-cartesian-gnulinux1.10 however this package is not
>>>>>>> generated. I can't even find it in the control file (except the
>>>>>>> dependency). Is this because I disabled KDL?
>>>>>>
>>>>>> Due to API instabilities in KDL, I had to drop the cartesian packages
>>>>>> from the control.common file. So this dependency (and the build dep)
>>>>>> needs to be removed
>>>>>> as well.
>>>>>>
>>>>>>>
>>>>>>> I'm also building debian packages of RTT and OCL for xenomai. In the
>>>>>>> generated control file only the package liborocos-rtt-xenomai1.10-dev
>>>>>>> has a dependency on xenomai.
>>>>>>
>>>>>> That is correct.
>>>>>>
>>>>>>> This looks like I can install
>>>>>>> orocos-xenomai without xenomai installed (when not installing the
>>>>>>> dev-packages). Is this correct?
>>>>>>
>>>>>> No :-] The dependency on libxenomai.so must be picked up by the
>>>>>> ${shlibs:Depends}
>>>>>> tag. Check the final dependencies with apt-cache show package-name
>>>>>>
>>>>>>>
>>>>>>> When building OCL packages for xenomai, a build dependency is missing.
>>>>>>> Only liborocos-rtt-corba-xenomai1.10-dev of RTT is required to build
>>>>>>> ocl, however liborocos-rtt-xenomai1.10-dev is also required. Else
>>>>>>> cmake complains that RTT for xenomai can not be found. Is this a
>>>>>>> missing build dependency or is this a missing dependency on
>>>>>>> liborocos-rtt-corba-xenomai1.10-dev?
>>>>>>
>>>>>> It looks like a bug in the rtt control-template.in file. The first
>>>>>> package, liborocos-rtt-corba- at TARGET@@LIBVER at -dev must also depend on
>>>>>> liborocos-rtt- at TARGET@@LIBVER at -dev
>>>>>> This dependency is missing.
>>>>>
>>>>> When I generate the control file for xenomai, no libxenomai-dev build
>>>>> dependency is required. results in:
>>>>>
>>>>> Orocos target is xenomai
>>>>> -- Optional library XENOMAI NOT FOUND. If the library is already
>>>>> installed, use the XENOMAI_ROOT_DIR environment variable or ccmake to
>>>>> set the missing variables manually.
>>>>
>>>> Oh, so both the build and package deps were wrong then ? Xenomai in
>>>> CMake shouldn't be optional either :-)
>>>>
>>>> It's a bug in create-control.sh which first replaces @BUILD_DEPS@ with
>>>> $bdeps, and then sets bdeps to something meaningful :/ Same for $tdev.
>>>> Same in OCL.
>>>>
>>>> The patches in attachment fix both rtt/ocl control file generation. It
>>>> seems it only worked if you specified one target (and even then only
>>>> gnulinux :)
>>>>
>>>> If you send me yours, I can commit all in one go.
>>>
>>> In RTT I modified control-template.in in order to fix the missing
>>> dependency of liborocos-rtt- at TARGET@@LIBVER at -dev.
>>>
>>> Libxenomai is indeed picked up.
>>>
>>> changes in ocl/debian:
>>>
>>> Added missing ocl-config.h + netcdf reporter header files in
>>> liborocos-ocl-sover-dev.install
>>> Added liborocos-reporting-netcdf.so in liborocos-ocl-template.install
>>> and liborocos-ocl-template-dev.install
>>> Added minimum required libcomedi version as build-dependency in control.common
>>> Added libnetcdf-dev + linux-libc-dev + libboost-program-options-dev as
>>> build-dependency in control.common
>>> Added libnetcdf-dev + linux-libc-dev as dependency in control-template.in
>>> Added RTSocketCAN in CMakeCanComedi.txt
>>> Added rule in liborocos-ocl-can-template.install and
>>> liborocos-ocl-can-template-dev.install to install rtsocket-can lib if
>>> it exists
>>> Removed liborocos-ocl-cartesian- at TARGET@@LIBVER@ as dependency in
>>> control-template.in
>>> Removed liborocos-kdl1.0-dev in control.common
>>
>> Thanks. I applied your patch with one minor change: require cmake >=2.6.2.
>
> Oh no! why? :-) We are building debian packages for etch and using
> cmake from backports version 2.6.0.

Ok, I'll revert that...

>
>>
>>>
>>> I don't know if it's required that libnetcdf-dev is added as a
>>> dependency in control-template.in. If I look in rtt there are also a
>>> lot of build-dependencies that are not added in control-template.in.
>>
>> They should be added. Which ones were missing in rtt ?
>
> libboost-program-options-dev | ?libboost-program-options1.35-dev |
> libboost-program-options1.36-dev | libboost-program-options1.37-dev
> libboost-thread-dev | libboost-thread1.35-dev |
> libboost-thread1.36-dev | libboost-thread1.37-dev
> libboost-test-dev | libboost-test1.35-dev | libboost-test1.36-dev |
> libboost-test1.37-dev
> tao-idl
> gperf-ace

Hmm. It depends. If on of our headers includes a header from boost
program options, or thread or...
then we need to specify it too as a dependency in our -dev packages.
So a build depend is not always
a package depend. In the above case, only boost-thread is a candidate,
and even then, it is only
enabled in Mac OS-x so not relevant for our debian build.

So none of the above must be added to the -dev packages.

>
> In OCL:
>
> libboost-program-options-dev | ?libboost-program-options1.35-dev |
> libboost-program-options1.36-dev | libboost-program-options1.37-dev
> (but that one is already installed in rtt-dev)
> libcomedi-dev in /control-template.in should also contain the minimum
> version number. (i.e >=0.8)
> pkg-config

Same here. libcomedi-dev is the only candidate we want to add with >=0.8

Peter

[prev in list] [next in list] [prev in thread] [next in thread]