From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DEF7D138CA4 for ; Sun, 3 May 2015 14:14:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 084B5E087E; Sun, 3 May 2015 14:14:12 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 032C9E085D for ; Sun, 3 May 2015 14:14:10 +0000 (UTC) Received: by pdea3 with SMTP id a3so140371079pde.3 for ; Sun, 03 May 2015 07:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=rLzSwpLNvba2vivZ9UeD1oapIKKEbpQxMYG0DkK+ewo=; b=UvV6QsFJMIb+kd8hantAizDkKfnbKEeAWhvtU9jYwTBuvtUW9qTmha0eo43zLTBX+e EFegKehLz6R/R2CWEMkgtTkxG63a1Y91d+j5KziwRSfd0g6BdNg5eLwsPAamav3jqopc PEmzKx6/e6KukfvN/p6HYD3k6gpUeC1YIO4v3g/MNwSz5vNiU8oQsYKidY1gHmmxnpvA nYBMBLeAO4Ro/8Ry+XzQOQHAAqtTq3SFpFwItoVjI7Ljccbg34+K6I/FMo6qEdWYbxBL u8+iQbNsxfwbf4LYF5l3k1rf7njCl5ItkSZZ0aP52MNyJ9V7XiUinK8UQRSq3TdPg7Xq JqCA== X-Received: by 10.68.226.37 with SMTP id rp5mr13668946pbc.21.1430662450154; Sun, 03 May 2015 07:14:10 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.70.29.131 with HTTP; Sun, 3 May 2015 07:13:49 -0700 (PDT) In-Reply-To: References: <20150424194217.0176adc0@googlemail.com> <553A91F6.7080505@gentoo.org> <553BA02E.7000805@gentoo.org> <20150425152317.20001.qmail@stuge.se> <553FE89B.2000903@gentoo.org> <5540C01C.7090202@gentoo.org> From: Georg Rudoy <0xd34df00d@gmail.com> Date: Sun, 3 May 2015 17:13:49 +0300 Message-ID: Subject: Re: [gentoo-dev] Re: RFC: c++14 global USE flag To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=e89a8ff2444f2294d105152e0fc6 X-Archives-Salt: f3b2c184-e2d1-461a-96b9-471ea2357781 X-Archives-Hash: fce0f61ba4445bdda67030f9ac8524b6 --e89a8ff2444f2294d105152e0fc6 Content-Type: text/plain; charset=UTF-8 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 --e89a8ff2444f2294d105152e0fc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.duncan@cox.ne= t>:
What about a somewhat more generic flag such as = newcode?=C2=A0 Like the bindist
or minimal flags, this could be global, but with local descriptions very strongly recommended.=C2=A0 Similarly, like minimal, setting it globally wo= uld
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.
<= div>
Nice idea, thanks! There are a couple of corner cases th= ough.
=C2=A0
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 (o= ptional) builds with say Qt6, and these could be toggled independently? Doe= s that imply having something like newcode_cpp17 and newcode_qt4 on per-pac= kage basis?
=C2=A0
and the = good bit is, generic meaning,
that USE=3Dnewcode 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 p= ulling of clang?

That's probably a way to go, = but feels like not Gentoo-way enough (just removing an option).
= =C2=A0
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.=C2=A0 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.

<= /div>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 d= efault (globally unmasked and per-package masks vs globally masked and per-= package unmasks), but that's a relatively minor one.
<= div>
--
=C2=A0 Georg Rudoy
--e89a8ff2444f2294d105152e0fc6--