media-gfx/darktable: comment on why we don't have sys-devel/gcc[graph…

…ite] in BDEPEND Yes, I HAVE tested these claims - both on the default amd64 stage3 system and using a configuration explicitly set up to prevent LLVM/Clang from being pulled in (emerged dev-lang/rust-bin by hand to satisfy virtual/rust + added */* -llvm VIDEO_CARDS: -* to package.use). Signed-off-by: Marek Szuba <[email protected]>
kerkmann · Dec 5, 2022 · a4a141f · a4a141f
1 parent 4aec428
commit a4a141f
Showing 1 changed file with 10 additions and 0 deletions.
diff --git a/media-gfx/darktable/darktable-4.0.1.ebuild b/media-gfx/darktable/darktable-4.0.1.ebuild
@@ -39,6 +39,16 @@ REQUIRED_USE="lua? ( ${LUA_REQUIRED_USE} )"
 
 RESTRICT="!test? ( test )"
 
+# It is sometimes requested, by both users and certain devs, to have sys-devel/gcc[graphite]
+# in BDEPEND. This has not been done *on purpose*, for the following reason:
+#  - darktable can also be built with sys-devel/clang so we'd have to have that, as an alternative,
+#    in BDEPEND too
+#  - there are at least two darktable dependencies (media-libs/mesa and virtual/rust) which
+#    by default pull in sys-devel/clang
+#  - as a result of the above, for most gcc users adding the above to BDEPEND is a no-op
+#    (and curiously enough, empirical observations suggest current versions of Portage are
+#    more likely to pull in Clang to build darktable with than to request enabling USE=graphite
+#    on GCC; that might be a bug though)
 BDEPEND="dev-util/intltool
 	virtual/pkgconfig
 	nls? ( sys-devel/gettext )