2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.duncan@cox.net>:

What about a somewhat more generic flag such as newcode? Like the bindist
or minimal flags, this could be global, but with local descriptions very
strongly recommended. Similarly, like minimal, setting it globally would
be strongly discouraged.

In this case, the newcode local description would be something like:

C++14 related: gcc doesn't support yet, requires clang

... with an appropriate use-conditional dep.

The newcode flag would however be generic enough that it could be reused
for C++17, etc, as well, and could obviously be phased out for any
particular package once its specific newcode dependencies are met in
stable -- in this case, when a supporting gcc stabilizes.

Nice idea, thanks! There are a couple of corner cases though.

newcode would even be generic enough to be used for say qt6 when the time
comes, if it turns out to be stuck in the qt overlay for quite some time,
as was qt5, for the longest time,

What if a package would support (optional) builds with C++17-related features and (optional) builds with say Qt6, and these could be toggled independently? Does that imply having something like newcode_cpp17 and newcode_qt4 on per-package basis?

and the good bit is, generic meaning,
that USE=newcode requires a dep that's still generally problematic or
might be considered excessive to get, for optional functionality that may
or may not be considered worth it, should be pretty obvious.

Does that imply that merely pulling clang for builds is not a newcode-concern then, and, back to the original topic, in case of leechcraft C++14 can be enabled unconditionally, again with unconditional pulling of clang?

That's probably a way to go, but feels like not Gentoo-way enough (just removing an option).

Making that meaning even more obvious would be the fact that the flag
would likely be packageuse-masked for many users for much of the the
time. That could for instance allow packages using it in-tree, before
the dep it pulls in is itself in-tree, while still making it possible to
unmask, for users who either already have the required overlay active, or
who don't have it active ATM, but are willing to activate it to get the
features it toggles.

Depending on the answer to the previous question, if all the deps are in-tree, then there is no need in masking the useflag. It could be unmasked on the per-package basis again, I guess? Then there is a question of the default (globally unmasked and per-package masks vs globally masked and per-package unmasks), but that's a relatively minor one.

Georg Rudoy