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

Doc target installs CMake build files when used with Debian's build system #554

Open
balbirthomas opened this issue Mar 21, 2019 · 1 comment

Comments

@balbirthomas
Copy link

I built a Debian package for Scopy. Please see https://github.com/balbirthomas/scopy/tree/debian. Debian has builtin support for packaging CMake software, using the --buildsystem=cmake option of debhelper(7) ( see debian/rules file). However when used with Scopy's CMake build system, this results in installing the entire CMake build tree (CMake temporary files, object files etc) into the Debian package and system. A work around is to turn off, installation of documenation using the -DWITH_DOC=OFF option to CMake.

I do not see any bug reported for debhelper on Debian's bug tracking system that could explain this behavior. It seems like some assumptions regarding install paths for the doc target, made in Scopy's CMakeLists, may be causing the issue. It should be possible to reproduce this by commenting out the override_dh_auto_configure: target (2 lines) in the debian/rules file or removing that entire commit. Do let me know how I can help in diagnosing and fixing the issue.

Also note this Debian package can not be upstreamed because of missing dependencies (though I have packaged them all). In particular Qwt multi-axes branch and patched version of GNURadio. The former I understand will be mainlined in Qwt 6.4 and will eventually make it into Debian. I am not aware of the mainlining situation with regard to GNURadio patches (trapezoid, phase and find volk). Hopefully there is a plan to mainline these too. It will be great to have an apt-get'able Scopy some day.

@adisuciu
Copy link
Contributor

Regarding GNURadio, we will fall back to master when GNURadio 3.8 releases. We will then create a GNURadio module that should contain everything we need.

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