Closed teythoon closed 3 years ago
@dewyatt As I understand, ruby-rnp is installed only to run tests via CI/and/or locally? What about separation of rnp and ruby-rnp, moving all ruby-related things to CI in separate (or updated) workflows?
Or, as a simpler solution, build with ruby-rnp only if specific option is given to cmake, like DBUILD_RUBY_RNP
Options in order of preference from my perspective:
ruby-rnp
are already installed (e.g. if ruby -r rnp -e ''
succeeds quietly), run some tests with already-installed ruby-rnp pointed toward the newly-built librnp (probably via LD_LIBRARY_PATH
)DTEST_RUBY_RNP
is set, run some tests against the already-installed ruby-rnp, failing if ruby or ruby-rnp are not presentDBUILD_RUBY_RNP
is set, use its value to try to build ruby-rnp (presumably running tests associated with that gem). The value of DBUILD_RUBY_RNP
could be:
v
, in which case it points to https://github.com/rnpgp/ruby-rnp/releases/tag/<VALUE>.tgz
Description
When I do
make
, some ruby installer magic asks me to use sudo to install the gem. There are two problems with this. First, this is the build phase, not the install phase. Second, this disregards CMAKE_INSTALL_PREFIX.Furthermore, when invoking the tests, cmake clones the ruby bindings to run its tests. There should be a way to disable this, because this won't work in build environments without network access. I guess the cloning of the ruby bindings happens now in the build phase too, and it is unacceptable for the same reasons.
Steps to Reproduce
Expected Behavior
RNP is built.
Actual Behavior
RNP is built, then I'm asked for my password to install the gem into locations unwritable for my user: