From nobody Fri Nov 26 21:47:38 2021 X-Original-To: freebsd-hackers@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 CEFA518C09E1 for ; Fri, 26 Nov 2021 21:47:42 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 4J17dV1WSWz4cNc for ; Fri, 26 Nov 2021 21:47:41 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-qv1-xf2b.google.com with SMTP id i13so8215791qvm.1 for ; Fri, 26 Nov 2021 13:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OESfpJi9gVYSZSnaWLUd7R8ok5a69arSJCD0hv7uXtg=; b=I/NzURUQuB+jPaZFV3/j06WaQFr4dwvjLZJ+Ip/6llNWQS74cVS7LHD8QV67WfMshi J3KNOGoBtE9x12IscLRn504QWalvbO//YM9fCLC44f2M75OiRhlh00C+RsiGL0yUgLJa BmP1fHue8n0yF04zF3p/jsVZuprqrC4/1KNe1f9zZkYv4aLDq8T11JETkUORSnYCgbxS 3T7DIGEMOdpkei5rWz8apxqfhR2uzJfKJFI8p+gbc1lkJXoHLeeQkgOVr+AxxmKfFOo2 Xe1ZDvhQsigznrAvd9Z8/nrLIP8GxcYxeQoPNuuErs0P4DIIj+au2Qz4aXLgtot0CBHf j5gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OESfpJi9gVYSZSnaWLUd7R8ok5a69arSJCD0hv7uXtg=; b=0qOQtgpHOFpIFiK7hKXcTM/Ms4yXQZFNml5qwxlWXykvfcKNYz+ofHFRG5Do+yqA5N TCTqEPatrxgEoCcG9Jt4yTVztlnFJEKBxENIBkuZ1IeSZDkb3QhO8EjlEmXPumX0r0ZG PciJoAJnKc6w3b6e7cdZE3I2r+mgXHh8A3EQmEVZ1ciItzm7QmC49IKpG+iYAarcIbY1 sAD+1ksWaVVCiLiC2XetNbnlKWcU8MGyB7RejOjW69L+bd4sIrtzth7JPRG6E1AYvhmF lht98cfmyPOOEUcBdqX0FQPkSa1ON10PoKszKtQpZ31HigZHnq9uY2aQsfY2FpXMOsWd LrzQ== X-Gm-Message-State: AOAM531N+DXLn456gpTwrVE+SK/+/1B67tYuyZGYUZzKyakX9TgRAKlh wVyyNHH+wwl4F9M1KUZ0L7LxM3o/lyV3SDgi X-Google-Smtp-Source: ABdhPJwC+81UT1J5f5qfhcpkspqakdZymWSkuECwvC2c4AbEbk4IylNhsKgWWPHs2/cy/k5QEWvc5A== X-Received: by 2002:ad4:5b82:: with SMTP id 2mr15942395qvp.90.1637963261202; Fri, 26 Nov 2021 13:47:41 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id x190sm3575590qkb.115.2021.11.26.13.47.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Nov 2021 13:47:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: Retiring WITHOUT_CXX From: Bakul Shah In-Reply-To: Date: Fri, 26 Nov 2021 13:47:38 -0800 Cc: "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers Content-Transfer-Encoding: 7bit Message-Id: <0C4C3821-52EE-43D5-94D0-B595F1269CD2@iitbombay.org> References: <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> To: Warner Losh X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Rspamd-Queue-Id: 4J17dV1WSWz4cNc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Nov 26, 2021, at 9:45 AM, Warner Losh wrote: > > On Fri, Nov 26, 2021 at 10:11 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > >> >> You can disagree with my assertion, but I shall continue to assert >> that it *seems* as if rather than adding B O S to the CI such that >> it is not only regularly tested, but continuously tested is the >> correct path forward here. > > > Testing all possible options takes on the order days. Testing all > possible combinations takes much longer. It's not practical to test > them all on every commit. It's computationally difficult. Would it make sense to define a number of option sets and test only those? This would reduce the test load from testing 2^N option sets to a much smaller number. I suspect *useful* combinations are far fewer than 2^N. > We do have to stop and consider the bigger picture: is it an option > that's useful enough to have it be one of the subset of things we test > on a regular basis, and enforce some sort of pre-commit requirements > for. Or is it an option we're content to test after the fact and have some > sane plan for remediation? Or is it an option that we've slavishly > carried forward from a time where it made a lot of sense to a time where > the situation on the ground is such that it no longer makes sense? It appears the following in /usr/src have .cc files: [ls **/*.cc|sed 's,/[^/]*$,,'|uniq] cddl/usr.sbin/zfsd cddl/usr.sbin/zfsd/tests cddl/usr.sbin/zfsd contrib/bsnmp/tests contrib/capsicum-test contrib/googletest/googlemock/src contrib/googletest/googlemock/test contrib/googletest/googletest/codegear contrib/googletest/googletest/samples contrib/googletest/googletest/src contrib/googletest/googletest/test contrib/googletest/googletest/xcode/Samples/FrameworkSample contrib/libcbor/oss-fuzz contrib/libcxxrt contrib/libucl/examples contrib/netbsd-tests/lib/libc/sync crypto/openssh/regress/misc/fuzz-harness lib/csu/tests lib/libc/tests/stdlib lib/libdevdctl lib/libdevdctl/tests lib/libnv/tests lib/libpmc sbin/devd tests/sys/fs/fusefs tools/tools/mcgrab tools/tools/mctest usr.bin/dtc usr.bin/users usr.sbin/pmc Looks like a lot of the .cc files are required for testing (that most users won't care about). I was surprised to see .cc files in lib/libc/tests/stdlib! There are only two .cc files here. lib/libpmc has just one. googletest's README.md says: Welcome to **Google Test**, Google's C++ test framework! If it will help I can rewrite devd in C, and may be more. I have a very small program that converts .dtb files to .dts. Adding a parser for .dts files wouldn't be hard (with usr.bin/dtc as a reference). Not trivial but doable. > That's the discussion we're having here. Is it important enough to require > everybody to pay attention to it or not... > > Warner