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 BF3A71381F3 for ; Mon, 23 Sep 2013 20:59:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B5511E0AFA; Mon, 23 Sep 2013 20:59:50 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E87B2E0AEE for ; Mon, 23 Sep 2013 20:59:49 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id x13so7642244ief.29 for ; Mon, 23 Sep 2013 13:59:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; bh=O9sdZ0wn2ZkZDuK4ODQrkFi/Wp0j08iHcjVmI/cDWCY=; b=a9oLF1+gSFDDMrrQ+bEigkltvbj3U9zejSsFwYj23Pylhf35UaSWD2GAELNag1w4F5 XePmrGummb0FHP0e5XyvfPrxgaS2PGvm96s8v0O10eAL267aWjy96EZE4ZVyeR+VDYg/ 2PysWHN0AmHIJhzhowLJPbTOgVmpm952tE1hsmavleL0AG5MC5Yyt/YJc9+XoE7Ct0tI oahp6mcxSoUo12/dt4Dzvh+6Uw+OoTVhihKfHibP5WKq7UMNV27KqU4wTNA5crnbkATw 1v4Pr9WWzwSPG2I0EvmdELcwfmGK2H/UimZ7gUxzzDYuglPj+URsWcJ0IKYNmTzKNZQO YOEg== X-Gm-Message-State: ALoCoQn7Q2Z7nqiIo1wWgX9axAa7N+gz1KSwf1HwDv90PMK9rcnXpYdYxzk+szT8L9LhKYIXPFGo 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 X-Received: by 10.43.3.196 with SMTP id nz4mr2897449icb.74.1379969988883; Mon, 23 Sep 2013 13:59:48 -0700 (PDT) Sender: gmt@be-evil.net Received: by 10.64.33.239 with HTTP; Mon, 23 Sep 2013 13:59:48 -0700 (PDT) X-Originating-IP: [75.147.143.253] Date: Mon, 23 Sep 2013 13:59:48 -0700 X-Google-Sender-Auth: WgfIHFXRuDG4lm5c4wx0w_ghsd8 Message-ID: Subject: Re: [gentoo-dev] [PATCHES] Sub-phase functions in autotools-utils & autotools-multilib From: Greg Turner To: gentoo-dev@lists.gentoo.org Cc: reavertm@gentoo.org, multilib@gentoo.org, =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 357aeffc-7a9a-4bbf-b3c8-dde512b75641 X-Archives-Hash: f27b993e11f24b55c482e11f00348004 On Thu, May 2, 2013 at 5:26 AM, Micha=C5=82 G=C3=B3rny = wrote: > Hi, > > I've thought for a bit and got the conclusion that the best solution > for quite an irritating syntax of autotools-multilib is to use > sub-phase functions. Sorry for the delayed response, but having been playing with this stuff lately, and I'd like to state for the record that I whole-heartedly endorse this product and/or service. > autotools_configure() > autotools_install() > autotools_install_all() I like that you manage to avoid syntax like: autotools_multilib_${phase}_${applicability-specifier}_${etc}... :) The name of the game is to get from where we are now, to where we want to be (presumably, a future in which we can rm -rf ${PORTDIR}/app-emulation/emul-linux-x86-*), with a minimum of repetitive and/or difficult retrofit labor. Ideally, to multilib-retrofit an ebuild, the ebuild-repair-person would just chop up the code a bit, and indicate to the framework which snippets pertain to which ABI's or are ABI-independent. We're nowhere near that now. As you suggest, the problem is that there's no way to "hook" any per-ABI script code into the autotools-multilib phase functions without copy pasting the whole boilerplate, which shrinks the value-proposition of autotools-multilib (vs. direct inheritance to multilib-build) down to almost nothing. All but the most simple pre-USE_EXPAND-abi-ebuilds have snippets of script code that want to run on a per-ABI basis, often inconveniently interspersed between src_prepare() and src_configure(), and there is no low-effort way to wedge that code into the autotools-multilib framework as implemented. Often, there is some clever substitution that can be made to bridge this feature-gap -- but by now the ebuild-repair-person is well into "investigating/thinking deeply/drawing-board" mode, precisely where he doesn't want to find himself if he's trying to quickly blow through a deeply-entangled batch of 50 or 100 ebuilds requiring simultaneous retrofitting. > While this seems rather cosmetic... It's not just a cosmetic problem. ... but, a brief diversion about aesthetics: I think, in ebuild-writing, there's a fine line between cosmetically fucked and just plain fucked. Likewise, the converse also holds: an aesthetically blessed ebuild is probably blessed for developers, bugzilla worker-bees, and end-users (gentoo sysadmins) alike. So, in short, cosmetic improvements are good and intrinsically important. Furthermore, the term "cosmetic" has connotations of "ineffectual": that is not the case here, there are real practical problems being solved -- your proposal ENABLES the ebuild-repair-person to shuffle around code in a seemingly trivial manner, but that's NOT an option with the current implementation, instead the ebuild-repair-person must struggle against the limitations of the framework (in addition to figuring out whatever true semantic change is required by the retrofit). Anyhow, meanwhile, back on planet Earth... > The sub-phases without '_all' suffix are run inside BUILD_DIR, and > repeated for each multilib ABI. The sub-phases with '_all' are always > run only once, and inside S. It's clearly a move in the right direction. New choke points would probably reveal themselves once we were freed from the tyranny of constantly typing in the same code over and over :) I do think "all" vs. "" is dsylexia-inducing and should be changed... perha= ps: at_${phase}_abi: per-abi steps (i.e., probably in per-abi ${BUILD_DIR}) at_${phase}: global steps (i.e., in ${S}) s/at/autotools/ obv.... or just leave it! short=3D=3Dgood here. Anyhow, those really are trivial semantic matters. I also think your proposal could go a bit further in the ability to slice-and-dice the sub-phase functions. For example, there might be uses for granularity like: at_${phase}: as before at_${phase}_all: as before at_${phase}_${ABI}: single-abi-specific stuff executed before at_${phase}, i.e., platform-specific configure tweaks at_${phase}_best: stuff that needs to happen in ${BUILD_DIR}, but should only happen for DEFAULT_ABI, i.e.:, compile documentation from source, full emake installs to deploy unwrapped header files and /usr/share/doc stuff, etc. Cross-compile support might suggest a couple of additional sub-phases (i.e.: a sub-phase to generate ${CBUILD}-targeted intermediate tools (perhaps only during cross-compiles, but I really wish somehow that could be coded just once, tagged, and the framework could decide whether to do anything unusual with it based on context. > What are your thoughts? The patch is sent in reply to this mail. Just saw your message that you are abandoning this proposal due to lack of interest. I think the lack of comments is not particularly surprising. How many people are actively getting their hands dirty attempting to mass-retrofit ebuilds for USE_EXPAND abi-based multilib? I'd wager you're the only one, unless you want to count me over the last 24 hours or so but I'm just dabbling and will probably lose interest. In other words, probably you are the only person in a position to see what the requirements are. If you are concerned about building stuff with no "eyeballs" / feedback, then put them in new eclasses instead of fixing the old ones (it's 'prolly better for back-compatibility to do so anyhow). But I'm 100% convinced you're on the right track because I was about to start building what you described myself (and I'm /never/ wrong! hahaha, ok, far from it, but as they say, "even if I do say so myself...") -gmt