From nobody Thu Mar 9 17:54:20 2023 X-Original-To: dev-commits-src-all@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 4PXcJS6fQQz3xCSM for ; Thu, 9 Mar 2023 17:54:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PXcJS4ttWz4Jns for ; Thu, 9 Mar 2023 17:54:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x531.google.com with SMTP id u9so10387257edd.2 for ; Thu, 09 Mar 2023 09:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; t=1678384471; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qY5br9gHsEMP7vLtjgz8Y7zmJkTgHg/0Z2TFJAqalN8=; b=orKVoogOhUzYorlBOBMLHKwKTUOfs0wT6jkmExf9uHrFKZiFodter2k0P0EB72VcD3 QauMpKCp6pRo0GW4BaFu3zaTEfVqXbIxcOtyDoj28bNCzROZIgjs9VyNlJ0cv5Q/P+JK OHuAL7KpE9Fg1koCwsaiNGMQ7z2XpVEzPCmc4cFtR9YJMLVhcgjAHNqdgQQwmNhKOEWx McyQD9h/SqY+TbO9YbL/vFcmbNGueEx8pWgwdL50agp0NSReTjfJVEv4m6Bv/Pfkc5Ef LQrfJfRhMbc/nrhzNMDBkEDAxx68W77lYgP0RCMSwalva8y9wXrF0IkycNAMxB9+CFCF M5aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678384471; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qY5br9gHsEMP7vLtjgz8Y7zmJkTgHg/0Z2TFJAqalN8=; b=x6yVfRfgcTW/utBcOl5pzn99psJH/5fuKEwkypRDwsVHuyGQ0L5RTfUP+L6kgX8ElV iLyzRRmNOq/M4ZEL5zCWlWBsXJUg4LRmZV4kIaa9a49NmZ4Zstdv2EBIH7z4mrcx4Snv uAjCzZqhMFf83AvcP89y3C32SM6eTSgqKZFxV5KdyCgWUBqp5cTTEaOlBKWh1qQwLNlp lERZ10PEV44WNH6678ouePI4YjqhLtX5Z1mi23xlQhkSO0sRdqJvoJQSKciI/ZuZ7Dln novX3iCT4kD6b7YL3177uawr2VSwvvxAl3WMnM8+N0B8wzJRmT2dn8m5ilDvdTK+q716 As8w== X-Gm-Message-State: AO0yUKUKWH+1+iKT4UGEhsLNNbuiJ3m5BCGA4mHSoWV3AU/Lbupx2q1f 9KLv6AKcaHymNeIfk3iUssejnw+QffVxOyQpaAOzz26P7zx2cs2u X-Google-Smtp-Source: AK7set/uMQawIPOp373qNjC85kPLYVxr50Ybu0LQ3NxytDcoHa62ypbv5hP9Oqk+hUk1liGDmqh2rVVMRWN1D3lRSgk= X-Received: by 2002:a50:aa95:0:b0:4ad:7439:cecb with SMTP id q21-20020a50aa95000000b004ad7439cecbmr12747195edc.7.1678384471352; Thu, 09 Mar 2023 09:54:31 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202303082331.328NViDn050541@gitrepo.freebsd.org> <7a33ffb1-f46f-fd57-b142-fc8641d923df@FreeBSD.org> In-Reply-To: <7a33ffb1-f46f-fd57-b142-fc8641d923df@FreeBSD.org> From: Warner Losh Date: Thu, 9 Mar 2023 10:54:20 -0700 Message-ID: Subject: Re: git: c581962414ed - main - src.conf.5: Add some WITH_/WITHOUT_ option descriptions To: John Baldwin Cc: Ed Maste , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="00000000000036360305f67b5686" X-Rspamd-Queue-Id: 4PXcJS4ttWz4Jns X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000036360305f67b5686 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2023 at 10:30=E2=80=AFAM John Baldwin wrot= e: > On 3/9/23 7:10 AM, Ed Maste wrote: > > On Wed, 8 Mar 2023 at 23:12, Warner Losh wrote: > >> > >> Yea, there's no reason to have the description twice... > > > > It looks like the ones that have both WITH_ and WITHOUT_ descriptions > are: > > > > ATM AUTO_OBJ BIND_NOW CLANG CLANG_BOOTSTRAP CLANG_FULL CXGBETOOL > > DEBUG_FILES EFI FDT GCC GCC_BOOTSTRAP GCOV GDB GH_BC GNU_DIFF > > GOOGLETEST HYPERV KERNEL_RETPOLINE LIB32 LLD LLD_BOOTSTRAP LLD_IS_LD > > LLDB LLVM_ASSERTIONS LLVM_COV LLVM_CXXFILT LLVM_TARGET_AARCH64 > > LLVM_TARGET_ALL LLVM_TARGET_ARM LLVM_TARGET_MIPS LLVM_TARGET_POWERPC > > LLVM_TARGET_RISCV LLVM_TARGET_SPARC LLVM_TARGET_X86 LOADER_GELI > > LOADER_KBOOT LOADER_LUA LOADER_OFW LOADER_UBOOT MALLOC_PRODUCTION > > MLX5TOOL MODULE_DRM MODULE_DRM2 NVME OFED OPENMP OPENSSL_KTLS PIE > > PROFILE RELRO REPRODUCIBLE_BUILD RETPOLINE SENDMAIL SHARED_TOOLCHAIN > > SSP STATS SYSTEM_COMPILER SYSTEM_LINKER TCP_WRAPPERS UNIFIED_OBJDIR > > USB_GADGET_EXAMPLES ZFS > > > > although not all of them are used (the ones that default on across all > > architectures). > > > > Looking at src.conf.5 the duplicates I see are: > > > > CXGBETOOL EFI FDT HYPERV LIB32 LLDB LOADER_GELI LOADER_KBOOT > > LOADER_LUA LOADER_OFW LOADER_UBOOT MLX5TOOL NVME OFED OPENMP > > OPENSSL_KTLS PIE ZFS > > > > Perhaps for these cases we can just skip the negative sense > > (WITHOUT_), just listing the architectures it applies to? > > > > Something like: > > > > WITH_CXGBETOOL > > Build cxgbetool(8) > > > > This is the default setting on amd64/amd64, arm64/aarch64= , > > i386/i386, powerpc/powerpc64 and powerpc/powerpc64le. > > > > WITHOUT_CXGBETOOL is the default setting on amd64/amd64, > > arm64/aarch64, i386/i386, powerpc/powerpc64 and > > powerpc/powerpc64le. > > My first thought was your first suggestion (a single FOO file that > permitted a common prefix for the with/without cases). However, your > second suggestion above is also fine and is probably easier to > implement? > > The other wrinkle is that we don't really handle BROKEN_OPTIONS ideally. > We just list the FOO option as defaulting to WITHOUT without telling > the user that actually it will fail to build if you enable it. Not > sure how much work that would be to fix. > Yes. Broken options are hard-wired to no on the platform. The current tooling doesn't account for this (but I suppose the script could be enhanced since it will just be in the BROKEN_OPTIONS list). I can toss an '.error' in when a WITH_FOO is defined or MK_FOO=3Dyes for a BROKEN option, but nobody has complained about this issue in the maybe 20 years we've been doing it. Warner --00000000000036360305f67b5686 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 9, 2023 at 10:30=E2=80=AF= AM John Baldwin <jhb@freebsd.org&= gt; wrote:
On 3/= 9/23 7:10 AM, Ed Maste wrote:
> On Wed, 8 Mar 2023 at 23:12, Warner Losh <imp@bsdimp.com> wrote:
>>
>> Yea, there's no reason to have the description twice...
>
> It looks like the ones that have both WITH_ and WITHOUT_ descriptions = are:
>
> ATM AUTO_OBJ BIND_NOW CLANG CLANG_BOOTSTRAP CLANG_FULL CXGBETOOL
> DEBUG_FILES EFI FDT GCC GCC_BOOTSTRAP GCOV GDB GH_BC GNU_DIFF
> GOOGLETEST HYPERV KERNEL_RETPOLINE LIB32 LLD LLD_BOOTSTRAP LLD_IS_LD > LLDB LLVM_ASSERTIONS LLVM_COV LLVM_CXXFILT LLVM_TARGET_AARCH64
> LLVM_TARGET_ALL LLVM_TARGET_ARM LLVM_TARGET_MIPS LLVM_TARGET_POWERPC > LLVM_TARGET_RISCV LLVM_TARGET_SPARC LLVM_TARGET_X86 LOADER_GELI
> LOADER_KBOOT LOADER_LUA LOADER_OFW LOADER_UBOOT MALLOC_PRODUCTION
> MLX5TOOL MODULE_DRM MODULE_DRM2 NVME OFED OPENMP OPENSSL_KTLS PIE
> PROFILE RELRO REPRODUCIBLE_BUILD RETPOLINE SENDMAIL SHARED_TOOLCHAIN > SSP STATS SYSTEM_COMPILER SYSTEM_LINKER TCP_WRAPPERS UNIFIED_OBJDIR > USB_GADGET_EXAMPLES ZFS
>
> although not all of them are used (the ones that default on across all=
> architectures).
>
> Looking at src.conf.5 the duplicates I see are:
>
> CXGBETOOL EFI FDT HYPERV LIB32 LLDB LOADER_GELI LOADER_KBOOT
> LOADER_LUA LOADER_OFW LOADER_UBOOT MLX5TOOL NVME OFED OPENMP=C2=A0 > OPENSSL_KTLS PIE ZFS
>
> Perhaps for these cases we can just skip the negative sense
> (WITHOUT_), just listing the architectures it applies to?
>
> Something like:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0WITH_CXGBETOOL
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Build cxgbetool(= 8)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is the defa= ult setting on amd64/amd64, arm64/aarch64,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i386/i386, power= pc/powerpc64 and powerpc/powerpc64le.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0WITHOUT_CXGBETOOL is the default setting on = amd64/amd64,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arm64/aarch64, i= 386/i386, powerpc/powerpc64 and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0powerpc/powerpc6= 4le.

My first thought was your first suggestion (a single FOO file that
permitted a common prefix for the with/without cases).=C2=A0 However, your<= br> second suggestion above is also fine and is probably easier to
implement?

The other wrinkle is that we don't really handle BROKEN_OPTIONS ideally= .
We just list the FOO option as defaulting to WITHOUT without telling
the user that actually it will fail to build if you enable it.=C2=A0 Not sure how much work that would be to fix.

Yes. Broken options are hard-wired to no on the platform. The current too= ling doesn't account for this (but I suppose the script could be enhanc= ed since it will just be in the BROKEN_OPTIONS list).

<= div>I can toss an '.error' in when a WITH_FOO is defined or MK_FOO= =3Dyes for a BROKEN option, but nobody has complained about this issue in t= he maybe 20 years we've been doing it.

Warner<= /div>
--00000000000036360305f67b5686--