Date: Fri, 26 Nov 2021 19:06:42 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Retiring WITHOUT_CXX Message-ID: <alpine.BSF.2.00.2111261838320.68830@ai.fobar.qr> In-Reply-To: <CAPyFy2Bs76J=UVotL6McqdHVNwhtYmfQq7U2xpXVKiQTpa78Lw@mail.gmail.com> References: <CAPyFy2DJcDFbSoD8awU03jPBY1YVytf%2Bxk4qpv3pW_GLkOsfWA@mail.gmail.com> <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> <CAPyFy2Bs76J=UVotL6McqdHVNwhtYmfQq7U2xpXVKiQTpa78Lw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Nov 2021, Ed Maste wrote:
> On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes
> <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
>>
>> So is the feature model of FreeBSD becoming, oh it gets broken
>> cause it is not regularly tested, so lets remove that feature.
>
> I don't agree with that. We have a large and growing CI infrastructure
> to regularly test functionality and are continually adding to it over
> time. But it's important to test and maintain what is actually used
> and is useful. Disabling C++ support made sense when obrien@ added the
> original knob in 2000, but it makes less sense today when parts of
> FreeBSD are written in C++.
I used to disable it in my images but started to need devd and that is
really the only reason its there currently
#WITHOUT_CXX= # devd needs it
I used to have a conversation with Warner a while ago about it and the
conclusion was the bits of C++ could be reimplemented in C if needed
but obviously no one ever got to that.
Maybe it would be good to list what it actually stops building.
- devd / libdevdctl
- a specific about libproc
- dtc
- atf / kyua
- zfsd
- users (that's a wow but okay); can't remember when I last typed that
- "toolchain" but that's a dead end for tiny images anyway
Ignoreing lib*.a it's still going to save 800-900k on libraries which
is a lot of dead weight if you don't need it and removing the knob
means one has to do it in post-processing on ones own so
re-implementing the wheel...
Even on 40MB images that is still more than 2% and I wish I could save
those every time. Finding a 2% performance improvement for the kernel
one wouldn't "waste" so easily.
Here's an example of what happens over time (compressed!) just to give
you an idea:
5.3M Dec 29 2007 base7-radiata-200712290220.gz
11M Aug 10 2020 base13-radiata-r364080.gz
There's gazillions of things I'd rather remove or combine and things
which never made sense to me to be MK_* src.conf knobs really but the
explosion of options is elsewhere but not on CXX which never made more
sense than it did today.
my 2cts
/bz
--
Bjoern A. Zeeb r15:7
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.2111261838320.68830>