From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A860D15817D for ; Sun, 2 Jun 2024 19:08:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0CCEFE2AEE; Sun, 2 Jun 2024 19:08:15 +0000 (UTC) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C4E57E2AE8 for ; Sun, 2 Jun 2024 19:08:14 +0000 (UTC) Received: by mail-qk1-x72e.google.com with SMTP id af79cd13be357-794cbdc2314so252574185a.2 for ; Sun, 02 Jun 2024 12:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717355293; x=1717960093; darn=lists.gentoo.org; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=o8uf6qcGo14t0OSWOh0Q+Va1rEKZ7/Dbtj3jd0quZuU=; b=m1moEi2LTnHMJ0j903V2PIEL7tPEjznC34kIK7l1zTGWgad8xbz2ZfTFtQOibXpwhV ibwueSu/ZuDwgAVdMIruF4SnjadnCBk8ngmgG1Ui2yK1wQxj5ozp4oYx4vdo1YyDvQ5Z VMdyLICAoT1KtiqoMSrUDaas4kDTx/n12d58KWR+KIHW3aoXytM+H434qipwQoGjRS4E UPs/6SsPrqWunu1WHg7UgJoz8kinCtF6123BrWyIcOeLr5o65annQC8YUwI9bClEuRci FZY96I3uD2PwEywRMJNJctowc8IvPPQwBUAfOtJe1g+FJ9DlSOe4J8dN448YcQT54UkL /SyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717355293; x=1717960093; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o8uf6qcGo14t0OSWOh0Q+Va1rEKZ7/Dbtj3jd0quZuU=; b=ly8lX5rrh02WeEW5WgRUC8z+G6sSfZhWRW71iTSTTSZeq+ptea5bD0gLw9A8aWfxPu Z1sAZRzJGMjbJZPUgbcFf21OADl9ZZnPFRwniYt4Wn7PReqB0ytUt4DjjJ64yvXSn1O9 b10R/3881gjgpNNI55xRVj2f3aACNV+QuMhSkHq1m2Sbwg6UCAsiYUCX0voF+a9GdiX6 Lz3T6H4m+caw8Kry2MCOGw6nHs4fM6ESm2gM1K2Hgus6noA4hxs1UXTOyZuh7SeAFLHV BSBGmCCMGAHZmTTobBldrusSpEKDC7gQJ7NJFGGEWhIU34rUveSevytPU4t3pQz3UaZU O1lw== X-Gm-Message-State: AOJu0YyZTMNDjVcnl3SUC96cGEvrtTiSfyfb5lOJU/UDrEoD81k4ULO0 Vq67OvTzzZb6vU9sjA/vPK5yZ4zYXnJ4I5IcKlGyyP1VORlLT+RPL2tY/Q== X-Google-Smtp-Source: AGHT+IHQWM/TquoL9OLS0oS4oBMLoguDiStVQINSibyZUzwralBsyJd0lGZkfyEPVYh0p3J1dXUdgQ== X-Received: by 2002:a05:620a:5650:b0:792:bad2:95d9 with SMTP id af79cd13be357-794f5ebf53dmr745735985a.59.1717355292938; Sun, 02 Jun 2024 12:08:12 -0700 (PDT) Received: from acleverhostname.lan ([2603:6011:3f0:69d0::12ac]) by smtp.gmail.com with ESMTPSA id af79cd13be357-794f2efc67csm221597585a.20.2024.06.02.12.08.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jun 2024 12:08:12 -0700 (PDT) From: Eli Schwartz To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [PATCH] meson.eclass: stop using the incomparably broken "meson compile" Date: Sun, 2 Jun 2024 15:08:07 -0400 Message-ID: <20240602190811.153615-1-eschwartz93@gmail.com> X-Mailer: git-send-email 2.44.2 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 4fafc02b-aa03-4303-8d8f-ba9556328b3d X-Archives-Hash: bf2af771535b0836f4a42a18731e7f2b With my upstream meson hat on, I have griped about this for years any time someone mentions "meson compile" to me. I think it was badly motivated and shouldn't exist. The purpose of this command is "for symmetry" with meson setup and meson test and meson install, even though all of those are python programs first and foremost, which have ninja targets that simply call back into the meson tool but with less control. Symmetry doesn't make a whole lot of sense. The compile phase actually is implemented as a... ninja file, not a python program. Using ninja directly is: - faster, since you don't load hundreds of python modules into memory, just to fork out to ninja - easier to control, since you can directly control the ninja arguments The "meson compile" program actually, in fact, only really exists for two reasons: - meson supports multiple backends -- only when manually requested -- on operating systems other than linux. Namely, VS on Windows, and xcode on macOS. The wrapper first checks which backend has been generated, and then runs the appropriate command there. It also provides the ninja argument syntax for options that multiple backends understand, so, you can pass -v -j8 and it actually works regardless of backend (even if in fact it has to pass `-verbosity:minimal -maxCpuCount:8` to do it). - via retconning, on Windows when using the MSVC `cl.exe` meson compile started actually adding this to PATH and setting it up (because it requires sourcing a batch script in order to both add to PATH and set inscrutable mandatory environment variables) to prevent ninja utterly failing if you missed this yourself. For portage purposes, neither of these matter whatsoever. Even if portage were to ever use cl.exe on Windows (???) it could set up the environment just fine on its own, and actually using alternative backends would require extending the eclass to configure xcode/vs for tremendous slowdown in compile time, which would be silly. In exchange for all these features portage doesn't need, what do we get? meson compile unabashedly doesn't support all possible ninja arguments, and says you should instead pass the combination of --ninja-args "..." --vs-args "..." --xcode-args "..." and it will figure out which ones are relevant for *your* backend and forward it to the backend. We don't actually do that -- it would be super ugly for the common case of -v -j8. As a result, we ignore $NINJAOPTS, which ninja-utils.eclass claims we are allowed to use. Instead we manually parse out some subset of "supported" values. We *cannot* respect NINJAOPTS anyways, because... ... meson compile sucks and cannot handle it. To be more accurate: it expects --ninja-args to be formatted using `meson-format-array`, the same format that machine files use. No thank you! And we still have to move to get_NINJAOPTS, then pass it as: ``` meson compile -C "${BUILD_DIR}" --ninja-args="['-j', '8', '-k', '0', '-v', '-l', '0']" ``` instead of: ``` meson compile -C "${BUILD_DIR}" -j 8 -v -l 0 --ninja-args="['-k0']" ``` The overengineered complexity of this is immense. ninja-utils.eclass exists for an extremely good reason, provides best practices, and means we don't have to maintain an interface to a custom tool with unintuitive behavior since we get precisely the common functionality we already want, for free. Just use eninja. Fixes: - the absolute inability to use standard $NINJAOPTS to fine-tune meson-using packages, for example to keep going and collect all the build errors before aborting with a failure. - support for ${NINJA_VERBOSE} (expected to be the fallback if MESON_VERBOSE isn't set) Signed-off-by: Eli Schwartz --- eclass/meson.eclass | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/eclass/meson.eclass b/eclass/meson.eclass index a22a85887584..a2bc5537e458 100644 --- a/eclass/meson.eclass +++ b/eclass/meson.eclass @@ -440,23 +440,11 @@ meson_src_compile() { pushd "${BUILD_DIR}" > /dev/null || die - local mesoncompileargs=( - --jobs "$(get_makeopts_jobs 0)" - --load-average "$(get_makeopts_loadavg 0)" - ) - case ${MESON_VERBOSE} in - OFF) ;; - *) mesoncompileargs+=( --verbose ) ;; + OFF) NINJA_VERBOSE=OFF eninja "$@" ;; + *) eninja "$@" ;; esac - - mesoncompileargs+=( "$@" ) - - set -- meson compile "${mesoncompileargs[@]}" - echo "$@" >&2 - "$@" local rv=$? - [[ ${rv} -eq 0 ]] || die -n "compile failed" popd > /dev/null || die return ${rv} -- 2.44.2