There's two issues here: 1) The non-standard approach to graphite, along with the comment in the ebuild: """ # 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) """ You should state the dependency correctly and file a Portage bug if it's doing something wrong. We also do this all the time for OpenMP and it's fine. (It also doesn't read consistently to me, given that if 3) is true, it doesn't sound like there's even a problem, i.e. 2) and 3) aren't consistent, but it's not a big deal because of the rest of this bug anyway). This keeps leading to confused users. 2) The graphite requirement appears obsolete as of 4.4.0 anyway (https://github.com/darktable-org/darktable/commit/b69b50a9c5ac30f4a3ee524723978463a85095b9). Please verify if that's the case and drop it if so.
1. Perhaps the comment you have quoted is not precise enough. However, it does NOT change the fact that when maekke and I got nagged about it last time, I tested what addingh BDEPEND="|| ( sys-devel/gcc[graphite] sys-devel/clang" to the ebuilds would do - and it resulted in Portage pulling in clang as a dependency of Mesa, followed by happily attempting to emerge darktable using non-Graphite gcc. Of course if you know how to solve this, you are very much welcome to let us know! 2. The commit in question removed Graphite requirement only from one bit of the code, there are still places where it is required. If you try emerging darktable yourself, you will see that versions up to and including 4.6.1 fail with sorry, unimplemented: Graphite loop optimizations cannot be used (isl is not available) when built using non-Graphite gcc.
I don't undertand why the line bellow is not on the "BDEPEND": || ( sys-devel/gcc[graphite] sys-devel/clang ) as Marek Szuba said. Any reasons to not include it? also, the ebuild has this text: "... 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" Isn't it the normal behaviour of portage, that if a dependency can't be filled and have an option, it tries to replace with the option? May be the problem is on the build time, it should default to one of them? I don't knot how to create a use flag to tell portage to use Clang or GCC, I would be happy to modify the ebuild and post it here if I knew.
In case this still persists in 5.0.0... ;) I think adding USE="+clang" (as default) is a better approach. Similarly to what firefox does. Enabling gcc[graphite] after the fact (remember, the current approach is better then BDEPEND but user will know what to do *after* build fails) is more work compared to... *no work at all* for desktop users who already have clang & llvm installed. Also this will still enable users to pick GCC if they so desire. As of writing (for the latest available version) I use a package.env with clang.
(In reply to Maciej Barć from comment #3) > In case this still persists in 5.0.0... ;) > > I think adding USE="+clang" (as default) is a better approach. Similarly to > what firefox does. > Yeah, I suppose this is an option. Although really, graphite is considered a kind of secondary thing where it's preferred to implement passes as part of GCC proper these days. So, another option would be to just make it optional via a patch, and warn when -graphite and not using clang. > Enabling gcc[graphite] after the fact (remember, the current approach is > better then BDEPEND but user will know what to do *after* build fails) It wouldn't be BDEPEND by itself.
(In reply to Marek Szuba (RETIRED) from comment #1) > 1. Perhaps the comment you have quoted is not precise enough. However, it > does NOT change the fact that when maekke and I got nagged about it last > time, I tested what addingh BDEPEND="|| ( sys-devel/gcc[graphite] > sys-devel/clang" to the ebuilds would do - and it resulted in Portage > pulling in clang as a dependency of Mesa, followed by happily attempting to > emerge darktable using non-Graphite gcc. > > Of course if you know how to solve this, you are very much welcome to let us > know! No bug was ever filed for Portage for this, as far as I'm aware. It also doesn't justify it being wrong.
would something like that look reasonable? https://gitweb.gentoo.org/dev/maekke.git/tree/media-gfx/darktable/darktable-5.0.0-r1.ebuild https://gitweb.gentoo.org/dev/maekke.git/commit/?id=ed2d806c89cfacf0274b72c46ef8201b199e57fb
