Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

omniidl-python not explicitly searched for as dependency #99

Open
wxmerkt opened this issue Jan 27, 2019 · 5 comments
Open

omniidl-python not explicitly searched for as dependency #99

wxmerkt opened this issue Jan 27, 2019 · 5 comments
Assignees

Comments

@wxmerkt
Copy link
Contributor

wxmerkt commented Jan 27, 2019

  • When omniidl is not installed the CMake fails during configure.
  • However, omniidl-python not being present only fails during compilation.
@nim65s
Copy link
Member

nim65s commented Jan 28, 2019

Hi, and thanks for the report.

Unfortunately, this software is weirdly packaged and I am not sure how to detect it.

The omniidlexecutable is owned by the omniidl package on Ubuntu, but it is part of the omniORB upstream package.

The omniidl-python ubuntu package provides files that are part of the omniORBpy upstream package.

And other distributions provide it in different ways.

So in gepetto-viewer-corba, we check for omniORB, as it provides a .pc file, but this does not imply that the omniidl executable is available (it does in Fedora & ArchLinux for example, but not on Ubuntu).
And for the content of the omniidl-python ubuntu package, it is even harder, as omniORBpy does not provide a .pc file…

@wxmerkt
Copy link
Contributor Author

wxmerkt commented Jan 28, 2019

I see - perhaps having the list of to be installed dependencies (as a copy paste apt-get) in the README could resolve this.

We package our packages via the ROS buildfarm (even if not explicitly ROS dependent) and via catkin. It served us better as our previous pkg-config-self-written-scripts based approach in combatting dependency problems (we used MIT's pods approach before).

@nim65s
Copy link
Member

nim65s commented Jan 28, 2019

We should be able to generate this list for all of our packages, and put that in READMEs, which would avoid issues like this one. In fact, this list is already available and used to generate Dockerfiles for our CI.

But manually adding this list would lead to yet another documentation that will not be tested, then forgotten, and then out of date, as it is already the case in most of our packages…

About the ROS buildfarm, we tried at some point to use it, but we lack manpower. We should be able to try again after having automatized most maintenance tasks.

Meanwhile, robotpkg provides what we need, and is also providing an alternative ROS buildfarm, which help a growing number of people having troubles with the main one.

@wxmerkt
Copy link
Contributor Author

wxmerkt commented Jan 28, 2019

Are the Dockerfiles for the CI public? If so we could extract dependencies for there or link to it.

@nim65s
Copy link
Member

nim65s commented Jan 28, 2019

They are not yet publicly available, and it would requires as much job to put them public than to add the generate a part of the README.
I will do this in a few days.

@nim65s nim65s self-assigned this Jan 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants