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 DB0B1138010 for ; Thu, 6 Sep 2012 08:12:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 584A6E0803; Thu, 6 Sep 2012 08:12:29 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id CAE7EE045E for ; Thu, 6 Sep 2012 08:11:46 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2371950pbb.40 for ; Thu, 06 Sep 2012 01:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=hcs5IYhCVGagWZDwygbQjmzkmvJh/4+GgWkjO2bJoho=; b=ePxqsayGAKhY4ViDrVoO4lNTmqAom+8wnop0ixnBJcwQzF3ThIUo28Z+87t7UGZfWg egIj6Z2SNJ7n+oB0ckNfCiyGny3R5dbia5PWKPvC0a97Lvtju1IWEO0231NfeA0t4gQA Hwiy4LIGPrITg9kaFafH7AaKcYXmRFe2//3+MkACll4dilWG3iDvylBMhm//MuUsnvAX XWweiDp738pjuwJP73vE8h1wjRUT4uwHIJv22JDYg2G16SFllleV+R/djeh+g97q1tKG IuKz7VVBVRtPvHQZGFCtm6UuPTm1Rc6V2t8wSURk+LjS/yfmbOWO4+pvMy3ijs4QVM/Y GNTA== Received: by 10.68.234.98 with SMTP id ud2mr3595527pbc.165.1346919105923; Thu, 06 Sep 2012 01:11:45 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id mr2sm952557pbb.16.2012.09.06.01.11.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Sep 2012 01:11:44 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Thu, 06 Sep 2012 01:11:45 -0700 Date: Thu, 6 Sep 2012 01:11:45 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5? Message-ID: <20120906081145.GC18495@localhost> References: <50411874.4060204@gentoo.org> <20120831214611.088b3f50@googlemail.com> <50469795.2070901@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=us-ascii Content-Disposition: inline In-Reply-To: <50469795.2070901@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 4d430142-3f80-4277-9bad-c5a45ee2de43 X-Archives-Hash: 03f33970db33414fbcecb8e3632b599e On Wed, Sep 05, 2012 at 12:06:45AM +0000, Jorge Manuel B. S. Vicetto wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 31-08-2012 20:46, Ciaran McCreesh wrote: > > > > > Also, we're getting rather a lot of *DEPEND variables here... If > > we're making people make major changes to their deps, which for > > HDEPEND we definitely would be, then the "it's expensive since > > people would have to redo their deps" argument against a combined > > DEPENDENCIES variable goes out of the window, so we should rethink > > that too. > > I have to agree with Ciaran, instead of multiplying DEPEND variables, > it's probably time we move to a single DEPENDENCIES variable. Personally, my complaints re: it are that 1) while minor, the labels in some cases are overly verbose; recommendations instead of recommends, suggestions instead of suggests, etc. 2) An actual flaw in their design (imo): it tries to intermix two different forms of parsing, without any real justification for *why* beyond *hey look kids, I can!*; The two can intersect in slightly fucked up ways, case in point: DEPENDENCIES=" run+build: cat/the x? ( cat/cow test: y? ( cat/says z? ( cat/moo ))) Now, there may be some unstated rules that disallow that, but if that *is* allowed, that's frankly dumb. As to if it's disallowed, it's kind of a design flaw that the situation can occur requiring an explicit suppression. Rather than invent and try intermixing a secondary form, just using the existing strikes me as saner; either we can have a specific use_expand group like thus: DEPENDENCIES=" dep_run? ( cat/monkeys ) dep_run+build? ( cat/foo )" Or, preferable imo, do away w/ the +, use a more natural ',' for phase separation, and use ':'; DEPENDENCIES=" dep:run? ( cat/monkeys ) dep:run,build? ( cat/foo )" Doing it that way reuses the existing parsing infrastructure (good) via just requiring a change to the use validation machinery (easy if the PM is implemented sanely). It also is able to express things that exheres variation can't do as cleanly; considering build/fetch/post/run/test as the viable dep targets: DEPENDENCIES=" build+fetch+post+test: some-dep" vs DEPENDENCIES="!dep:run? ( some-dep )" I don't much expect that to occur, but the potential exists, thus mentioning it. One unstated fault re: DEPENDENCIES btw, is it will not play nice w/ exactly one of blocks. Treating '^^' as "exactly one of", consider: DEPENDENCIES=" ^^ ( run: cat/blah build: cat/dar cat/foon )" Is that a stupid dep? You bet your ass it is.. But it would have to be explicitly suppressed by the parser for any such construct- moreso, repoman would have to spot it which is slightly unfun. Finally, one note; while certain folk have been making lots of noise about DEPENDENCIES being the best thing since sliced bread, their isn't much comment about how one actually transitions to it without making eclass authors who have to support both pre-DEPENDENCIES, and post-DEPENDENCIES eapis happy; kind of swiss cheeses the hell out of the code frankly. A compatibility hack that stacks them is strongly advisable; something akin to the following: Literally, we do the following: inherit() { if eapi blah; then local DEPEND PDEPEND RDEPEND else fi if eapi blah; then local _deps=( ) _x for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do [ -n "${!_x}" ] && deps+=( "${!_x}" ) done [ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}" unset DEPEND RDEPEND PDEPEND _x _deps else fi } Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set the DEPENDENCIES directly; those that have to support multiple eapi's (aka, every fricking eclass that exists right now) can just use the old form, shifting into the new form as things progress. Either way, the dual parsing required for exheres version I'm -1 on; I'm generally wary of NIH modifications, but the form I've mentioned that reuses our existing machinery is +.5...ish... from my standpoint (+1 on the form, just kind of 'meh' on the single var angle despite mostly agreeing w/ the reasoning). Either way, on w/ the flaming/insinuations of idiocy/counter-insinuations of being a wee bit too friendly w/ sheep... ~harring