Date: Fri, 26 Nov 2021 13:47:38 -0800 From: Bakul Shah <bakul@iitbombay.org> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Ed Maste <emaste@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Retiring WITHOUT_CXX Message-ID: <0C4C3821-52EE-43D5-94D0-B595F1269CD2@iitbombay.org> In-Reply-To: <CANCZdfouFQR_=Q7wdfPfjphCO=txnMX0sw10mUF3FZzgHkNYYg@mail.gmail.com> References: <CAPyFy2Bs76J=UVotL6McqdHVNwhtYmfQq7U2xpXVKiQTpa78Lw@mail.gmail.com> <202111261709.1AQH9sHg025507@gndrsh.dnsmgr.net> <CANCZdfouFQR_=Q7wdfPfjphCO=txnMX0sw10mUF3FZzgHkNYYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 26, 2021, at 9:45 AM, Warner Losh <imp@bsdimp.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C4C3821-52EE-43D5-94D0-B595F1269CD2>