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 7D2B01393F4 for ; Sun, 13 Sep 2015 05:07:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D2DE921C051; Sun, 13 Sep 2015 05:07:08 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D5A8C21C006 for ; Sun, 13 Sep 2015 05:07:07 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZazVJ-000101-G9 for gentoo-dev@lists.gentoo.org; Sun, 13 Sep 2015 07:07:05 +0200 Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 13 Sep 2015 07:07:05 +0200 Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 13 Sep 2015 07:07:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: www-client/chromium gtk3 support Date: Sun, 13 Sep 2015 05:07:00 +0000 (UTC) Message-ID: References: <55EFDDAD.9030502@gentoo.org> <55EFDEC7.1070403@gentoo.org> <55F00BFD.7050804@gentoo.org> <55F12159.3020506@gentoo.org> <55F1439E.1070002@gentoo.org> <55F1C8AB.40005@gentoo.org> <55F1CA38.3050302@gentoo.org> <55F298D0.7020702@gentoo.org> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip98-167-165-199.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT af87825) X-Archives-Salt: e3b41e89-2672-420e-a71c-bb666ef73e7f X-Archives-Hash: c9eddf01608a786848fa3077409d519f Rich Freeman posted on Sat, 12 Sep 2015 06:48:13 -0400 as excerpted: > On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.duncan@cox.net> wrote: >> >> Just bite the bullet and create entire USE flag families such that an >> ebuild can choose the flag appropriate to how it actually uses it. >> AFAIK this would need EAPI help, for reasons given below, but it should >> be doable. >> >> gui >> gui-gtk >> gui-gtk-2 >> gui-gtk-3 >> gui-qt >> gui-qt-4 >> gui-qt-5 > > I'm going to have to read the rest of your email about 14 times to fully > grok it, LOL. I started with a paragraph describing each setting, and very quickly decided /that/ wasn't going to work! I was "in a maze of twisty passages, all different!"[1] So I tried the matrix/table. That was bad enough, but at least with the table, I could cover all possibilities systematically without losing track of where I was. Luckily, the logic can be written once and used by many. Additionally, once setup, ordinary ebuild maintainers won't have to worry about the logic matrix, they'll simply setup the vars describing the candidates, call the function, get a result, and act on it. To ordinary ebuild maintainers it can be as effectively black-box as a call to any EAPI/PM supplied function is, today. > but one thing that strikes me about this approach, and perhaps > mine as well, is that this assumes that USE=-gui should imply USE="-gtk > -qt" or similar. > > What if qt or gtk is used for more than just the GUI. What if the > console version of the program still uses other functions in these > toolkits besides window decoration/etc? You're expanding my realm of possibilities here, thanks! =:^) Good point, particularly since qt5 is modularized with the specific intent of making it useful for CLI-only as well. Except that no, the proposal does /not/ necessarily assume USE=-gui means USE=-qt and -gtk as well. While my example had nothing suggesting CLI, keep in mind that these are effectively hierarchy flags, with gui-* used as the example. This was a (possibly abridged, there's other GUI toolkits...) example of the use and logic of the gui-* flags, but use of other flags and flag- families in the same ebuild would certainly be possible. Presumably one such flag (and perhaps eventually flag-family, if called for) could be cli-qt-5. Meanwhile, keep in mind that as described, the ebuild would set the candidates, then call a function which would return the selected candidates to build. But that doesn't prevent the ebuild from using further logic with other flags, etc. So taking your example, the ebuild would do the whole gui-* flag family thing as I described, get the results for that, and could then either do another family setup and get more results, or could throw in more conventional flags. And one such flag, possibly individual at first, wold be cli-qt-5, controlling this option separately. If later there were enough such flags to make a cli-* family, existing ebuilds using cli- qt-5 would continue to use that individual flag, while revision-bumps or new versions could start using the cli-* family, setting it up using UH-* variables and calling the function again, getting a CLI result which could be used, just as they got a GUI result to use. --- [1] https://en.wikipedia.org/wiki/Colossal_Cave_Adventure -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman