Re: git: c581962414ed - main - src.conf.5: Add some WITH_/WITHOUT_ option descriptions

On Thu, Mar 9, 2023 at 10:30 AM John Baldwin <jhb@freebsd.org> 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
> > 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=yes for a
BROKEN option, but nobody has complained about this issue in the maybe 20
years we've been doing it.

Warner