[gentoo-dev] USE variable interaction in DEPEND

[Robert Coie]

I am working on an ebuild for the sound editor snd
<http://ccrma-www.stanford.edu/software/snd/>, and I have run into two
issues:

First, the default scripting language for snd is Guile.  There is a
configure-time option to use Ruby instead of Guile.  If Ruby is
enabled, Guile is no longer needed, but I am unclear as to the proper
way to express this in a DEPEND declaration.

My current approach is to use a shell variable at the top level of the
ebuild:

SND_SCRIPT_DEPEND=" ( dev-util/guile ) "
use ruby && SND_SCRIPT_DEPEND=" ( dev-lang/ruby ) "

...and then to include ${SND_SCRIPT_DEPEND} in the definition of
DEPEND, but I am completely unsure whether this is considered best
practice for ebuilds, or even whether it is allowed at all.

The second issue appears to have been discussed on this list in May in
a thread about USE variable priority, but I was unable to find a
consensus.  The approach taken by the xemacs-gamma maintainer seems to
be closest to what I am currently doing, but still requires
dependencies for all toolkits, even though only one is being used.
This is probably not such a big deal in practice, as one could
probably safely assume that if a user is bothering to define a USE
variable for something, she would be very unlikely to be upset at
having its core libraries installed.

snd can use either motif or gtk+ as a GUI toolkit, and an inherent
ambiguity develops if a user has both USE variables defined.  I chose
motif as the default, as the upstream author indicates in the
configure instructions that the motif port is considerably more robust
than the gtk one.  So I did this:

SND_WIDGET_DEPEND=""
use gtk && SND_WIDGET_DEPEND=" ( x11-libs/gtk+ ) "
use motif && SND_WIDGET_DEPEND=" ( x11-libs/openmotif ) "

...and so here's a partial definition of DEPEND:

DEPEND="virtual/glibc
	${SND_WIDGET_DEPEND}
	${SND_SCRIPT_DEPEND}"

I'm not terribly happy about the namespace pollution, and can't escape
the nagging suspicion that I am breaking a core ebuild rule (or
several?), and would appreciate advice.

-- 
Robert Coie <rac@××××××××××.jp>
Implementor, Apropos Ltd.