Created attachment 278261 [details, diff] ruby-ng.eclass-optional-implementations-depend.patch When an ebuild sets RUBY_OPTIONAL=yes, it is suddenly responsible to run the following loop in the global scope on its own: for _ruby_implementation in ${USE_RUBY}; do DEPEND+=" ruby? ( ruby_targets_${_ruby_implementation}? ( $(ruby_implementation_depend $_ruby_implementation) ) )" RDEPEND+=" ruby? ( ruby_targets_${_ruby_implementation}? ( $(ruby_implementation_depend $_ruby_implementation) ) )" done (This example assumes a library which provides a ruby interface wrapper which can be optionally installed if USE=ruby is enabled). As seen above, this (untested, sorry) code should be correct: it only uses the publically exposed ruby_implementation_depend() function. However, it depends on something that is slightly internal to the ruby-ng.eclass -- the use of ruby_targets_${ruby_target} which is normally hidden by ruby_add_rdepend() and ruby_add_bdepend(). Also, this sort of code would likely be needed by certain ebuilds and/or ebuild authors will consider hardcoding the results of running this code to provide optional ruby support. I propose the function ruby_implementations_depend(). This function unfortunately has a very similar name to ruby_implementation_depend(). This function outputs the string which ruby-ng.eclass normally appends to RDEPEND and DEPEND when RUBY_OPTIONAL is unset. Use example: EAPI=4 RUBY_OPTIONAL=yes USE_RUBY=ruby18\ ruby19 inherit ruby-ng IUSE="ruby" DEPEND="ruby? ( $(ruby_implementations_depend) )" RDEPEND="${RDEPEND}" Patch was tested by examining ${T}/environment to confirm that RUBY_OPTIONAL=yes has the same effect, having RUBY_OPTIONAL unset has the same effect, and that using $(ruby_implementations_depend) have expected effects upon DEPEND and RDEPEND.
I discussed this briefly with Nathan on IRC already. Patch looks good to me. Alex, Diego: please review also and provide feedback.
LGTM.
Applied to ruby-ng.eclass. Thanks!
