Closed vermaete closed 4 years ago
They would be in a "-dev" or "-devel" sort of package, not needed for runtime deployment.
Yes, they should be in the opendds-dev package. What was your build environment? I built this using poky against warrior and zeus branches and had no problem.
This is the -dev package it produced
warrior/tmp/work/i586-poky-linux//opendds/3.14-r0/packages-split/opendds-dev/usr/lib/
├── cmake
│ └── OpenDDS
│ ├── api_macros.cmake
│ ├── config.cmake
│ ├── dds_idl_sources.cmake
│ ├── init.cmake
│ ├── OpenDDSConfig.cmake
│ ├── OpenDDSConfigVersion.cmake
│ ├── options.cmake
│ └── tao_idl_sources.cmake
├── libACE.so -> libACE.so.6.2a_p18
├── libOpenDDS_Dcps.so -> libOpenDDS_Dcps.so.3.14.0
├── libOpenDDS_FACE.so -> libOpenDDS_FACE.so.3.14.0
├── libOpenDDS_Federator.so -> libOpenDDS_Federator.so.3.14.0
├── libOpenDDS_InfoRepoDiscovery.so -> libOpenDDS_InfoRepoDiscovery.so.3.14.0
├── libOpenDDS_InfoRepoLib.so -> libOpenDDS_InfoRepoLib.so.3.14.0
├── libOpenDDS_InfoRepoServ.so -> libOpenDDS_InfoRepoServ.so.3.14.0
├── libOpenDDS_Model.so -> libOpenDDS_Model.so.3.14.0
├── libOpenDDS_monitor.so -> libOpenDDS_monitor.so.3.14.0
├── libOpenDDS_Multicast.so -> libOpenDDS_Multicast.so.3.14.0
├── libOpenDDS_Rtps.so -> libOpenDDS_Rtps.so.3.14.0
├── libOpenDDS_Rtps_Udp.so -> libOpenDDS_Rtps_Udp.so.3.14.0
├── libOpenDDS_Shmem.so -> libOpenDDS_Shmem.so.3.14.0
├── libOpenDDS_Tcp.so -> libOpenDDS_Tcp.so.3.14.0
├── libOpenDDS_Udp.so -> libOpenDDS_Udp.so.3.14.0
├── libTAO_AnyTypeCode.so -> libTAO_AnyTypeCode.so.2.2a_p18
├── libTAO_Async_IORTable.so -> libTAO_Async_IORTable.so.2.2a_p18
├── libTAO_BiDirGIOP.so -> libTAO_BiDirGIOP.so.2.2a_p18
├── libTAO_CodecFactory.so -> libTAO_CodecFactory.so.2.2a_p18
├── libTAO_Codeset.so -> libTAO_Codeset.so.2.2a_p18
├── libTAO_CSD_Framework.so -> libTAO_CSD_Framework.so.2.2a_p18
├── libTAO_CSD_ThreadPool.so -> libTAO_CSD_ThreadPool.so.2.2a_p18
├── libTAO_DynamicInterface.so -> libTAO_DynamicInterface.so.2.2a_p18
├── libTAO_IDL_FE.so -> libTAO_IDL_FE.so.2.2a_p18
├── libTAO_ImR_Client.so -> libTAO_ImR_Client.so.2.2a_p18
├── libTAO_IORManip.so -> libTAO_IORManip.so.2.2a_p18
├── libTAO_IORTable.so -> libTAO_IORTable.so.2.2a_p18
├── libTAO_Messaging.so -> libTAO_Messaging.so.2.2a_p18
├── libTAO_PI.so -> libTAO_PI.so.2.2a_p18
├── libTAO_PortableServer.so -> libTAO_PortableServer.so.2.2a_p18
├── libTAO.so -> libTAO.so.2.2a_p18
├── libTAO_Svc_Utils.so -> libTAO_Svc_Utils.so.2.2a_p18
├── libTAO_Valuetype.so -> libTAO_Valuetype.so.2.2a_p18
└── pkgconfig
├── ACE.pc
├── TAO_AnyTypeCode.pc
├── TAO_Async_IORTable.pc
├── TAO_BiDirGIOP.pc
├── TAO_CodecFactory.pc
├── TAO_CSD_Framework.pc
├── TAO_CSD_ThreadPool.pc
├── TAO_DynamicInterface.pc
├── TAO_ImR_Client.pc
├── TAO_IORManip.pc
├── TAO_IORTable.pc
├── TAO_Messaging.pc
├── TAO.pc
├── TAO_PI.pc
├── TAO_PortableServer.pc
├── TAO_Svc_Utils.pc
└── TAO_Valuetype.pc
3 directories, 58 files
It's at sumu with OpenDDS 3.14 and configured with --doc-group. And the master of meta-opendds. Anyhow: I will give it soon a try with a more recent version of Yocto.
The master branch is never guaranteed to build, but usually matches the most recent supported Yocto release. That may be unconventional for many repos, but it's routine for Yocto meta-layers.
Sumo was never supported, only thud and warrior at present, with zeus coming soon (warrior branch does appear to build against zeus)
My apologies .. rocko and sumo were also supported. But you need to use the sumo branch of meta-opendds
So. to be clear, you use the branch from this repository which matches the version of Yocto you are building against. Each branch supports a specific version of OpenDDS.
If you want to build OpenDDS 3.14 you need to use yocto/warrior and the warrior branch of this repo.
If you really want to build OpenDDS 3.14 against sumo you can try and backport the recipe from the warrior branch in your own fork or layer.
Generally, yocto meta-layer maintainers don't upgrade package versions between yocto releases as that has the potential to break the builds of people already using them. Instead they wait for the next yocto release and bring in the new versions at that time. The exception would be for minor or patch updates which require no changes in the calling code.
Hi, Thanks for the support. I can confirm this isn't an issue on Dunfell.
Why would you install the cmake files? My guess it these could be remove?