From nobody Tue Oct 5 20:48:14 2021 X-Original-To: dev-commits-ports-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5867412D14BA; Tue, 5 Oct 2021 20:48:16 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HP8mw237Bz3M23; Tue, 5 Oct 2021 20:48:16 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from mandree.no-ip.org (p54a03bfd.dip0.t-ipconnect.de [84.160.59.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mandree/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 08B024A84; Tue, 5 Oct 2021 20:48:16 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by ryzen.an3e.de (Postfix) with ESMTP id D7AF5120166; Tue, 5 Oct 2021 22:48:14 +0200 (CEST) Message-ID: <607e0aa1-3888-8a61-f80f-0aad1d53ea23@FreeBSD.org> Date: Tue, 5 Oct 2021 22:48:14 +0200 List-Id: Commits to the main branch of the FreeBSD ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-main@freebsd.org X-BeenThere: dev-commits-ports-main@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Content-Language: en-US To: Piotr Kubaj Cc: ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org, Mathieu Arnold References: <202109301834.18UIYKrL013410@gitrepo.freebsd.org> <20211004133056.z7e2iyrhlwprvvvp@aching.in.mat.cc> <20211005163152.gv2vwvg4nuqwga7q@aching.in.mat.cc> <44365771-0a1d-7bcb-2cb6-85f592624a3b@FreeBSD.org> From: Matthias Andree Subject: Re: git: fb5f03a87cf4 - main - Mk/bsd.lto.mk: add global LTO support for ports In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N Am 05.10.21 um 22:41 schrieb Piotr Kubaj: > On 21-10-05 22:04:32, Matthias Andree wrote: >> >> Am 05.10.21 um 18:49 schrieb Piotr Kubaj: >>> On 21-10-05 18:31:52, Mathieu Arnold wrote: >>>> On Tue, Oct 05, 2021 at 06:27:15PM +0200, Piotr Kubaj wrote: >>>>> On 21-10-04 15:30:56, Mathieu Arnold wrote: >>>>>> On Thu, Sep 30, 2021 at 06:34:20PM +0000, Piotr Kubaj wrote: >>>>>>> The branch main has been updated by pkubaj: >>>>>>> >>>>>>> URL: https://cgit.FreeBSD.org/ports/commit/?id=fb5f03a87cf432751fae1f0ae7f29c9d4fc65917 >>>>>>> >>>>>>> commit fb5f03a87cf432751fae1f0ae7f29c9d4fc65917 >>>>>>> Author: Piotr Kubaj >>>>>>> AuthorDate: 2021-09-30 18:27:50 +0000 >>>>>>> Commit: Piotr Kubaj >>>>>>> CommitDate: 2021-09-30 18:27:50 +0000 >>>>>>> >>>>>>> Mk/bsd.lto.mk: add global LTO support for ports >>>>>>> >>>>>>> It's well known that LTO provides both performance and size benefits for >>>>>>> binaries. >>>>>>> >>>>>>> Add preliminary, opt-in support for global LTO enforcement to ports. Ports that >>>>>>> provide LTO option on their own and the ones that don't work with LTO will need >>>>>>> to set LTO_UNSAFE in the future. >>>>>>> >>>>>>> PR: 258536 >>>>>> >>>>>> Not to be picky about approval and all, but this was added to the >>>>>> framework, and the framework is maintained by portmgr. When you want to >>>>>> add something to it, you must consult with portmgr before anything gets >>>>>> committed. >>>>>> >>>>>> In that case, we would have told you not to do it this way, but to make >>>>>> this a Mk/Uses/lto.mk. >>>>>> >>>>>> So please, turn this into a USES=lto. >>>>> >>>>> I did consult, but no one replied. >>>> >>>> There is absolutely no maintainer timeout for the framework, you cannot >>>> just add code there without explicit approval. >>> >>> And this is a port of a bigger issue, where portmgr ignores emails until numerously asked for (if one is lucky). >>> As one of users wrote in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251117, for which portmgr is assigned, "portmgr@ more and more feels to me like a black hole, or /dev/null: Anything sent there seems to disappear without effect." >>> >>> Since it was a change that doesn't change anything out-of-the-box, I decided to commit it. >>> >>>> >>>>> IMO adding it to USES is not a good idea, since USES are supposed to be used per port and my idea was to force LTO for all ports, same way that SSP already does. >>>> >>>> All I see in the patch is a USE_LTO knob, and a LTO_UNSAFE one, without >>>> any documentation of what it is for, what it does, what it might do, >>>> what it is about, or anything else. >>> Neither has SSP, I don't see any documentation for it (including commiter handbook which has just one line regarding USES=kmod at https://docs.freebsd.org/en/books/porters-handbook/book/#uses-kmod). >> >> Piotr, >> >> While I sympathize with your findings about portmgr@ 'responsiveness' >> having had my shares of ignores and brushes, I would tend to agree that >> we should not add undocumented knobs anywhere, so: >> >> 1. please add documentation including motivation > OK, just take note that there are several issues with it right now, so it's definitely not ready for use. E.g. libffi, perl and pkgconf don't build. > > Other than that, what is the best place for documentation? Do you mean porter's handbook? Assuming we're going the bsd.lto.mk path, the comment banner at the top of this new file would be the most obvious place. Purpose, how-to, reference. Anything else might be a proposal in whatever format. Talk to the doc committers or doceng@ maybe? > That's what we have package builders for. AFAIK they run Poudriere without ALLOW_MAKE_JOBS, so mostly single-threaded. > If LTO is ever enabled for everyone, we should still keep a knob to disable it globally. Yes, but my personal poudriere builders are on disk-space constrained VMs so get maximum parallelity within one job, and run few jobs in parallel. It's not ideal, but I can't build LLVM, Rust, and JDK or texmf in parallel with its truckloads-of-GBytes build directories. Before committing intrusive changes, we normally do -exp runs. Personally, for OpenEXR which is one of the more "central" ports I have, I dare building all ports depending on it locally before committing, if I couldn't do that I'd have to go for an -exp run. HTH