Date: Fri, 26 Jul 2024 04:26:17 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 280396] Mk/Uses/cmake.mk: Disallow USE_CSTD and USE_CXXSTD Message-ID: <bug-280396-7788-68hinJSbE7@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-280396-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-280396-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280396 --- Comment #7 from Jason E. Hale <jhale@FreeBSD.org> --- (In reply to Daniel Engberg from comment #5) > I'm not against utilizing USE_C*STD however I do think it also introduces= more "framework quirks" which might not be desirable. People are already s= truggling with remembering "common" helpers/macros and I don't think we nee= d to add more especially ones that have never been "announced" as in never = been mentioned in Porters Handbook. I don't quite follow. USE_CSTD and USE_CXXSTD are standard <bsd.port.mk> variables and are neither "framework quirks" nor remotely anything new. USE_CXXSTD and USE_CSTD were introduced over 10 [1] and 15 years ago [2] ye= ars ago, respectively. True, they are not mentioned anywhere in the PHB, but neither are USE_BINUTILS nor USE_LOCALE. Are you going after them next? The= PHB is an excellent guide, but isn't a complete truth source and using it as su= ch is a weak argument. Even the ports(7) manpage admits that the spread-out na= ture of ports documentation is a bug. Who is struggling, though? Maybe some contributors aren't always going to be making the right calls, but committers should definitely be familiar with b= asic ports infrastructure and correct those mistakes. The beauty of the ports framework is being able to quickly build a project without necessarily having to know the peculiarities of every build system, with the more detailed work being handled "behind the scenes" for the porte= r. It's basically an abstraction layer that I would expect to handle its own standard variables appropriately and not chide the porter for using them. > While BROKEN might be a bit too agressive I think there's benefit in bein= g a bit strict in this case as it makes overall maintaince easier, more con= sistent than having multiple ways to approach the same issue in. Who's maintenance time is being enhanced by converting standard ports varia= bles into lesser-known <build-system-of-the-month> arguments in individual Makefiles, when this could be more easily abstracted by the framework? Consistency is good and we have tools to check for the important things, but there's more than one right way to do the rest. For example, I personally prefer using pipes (|) as delimiters in REINPLACE_CMD arguments, but some u= se slashes (/) or commas (,). [1] https://cgit.freebsd.org/ports/commit/Mk/bsd.port.mk?id=3Dc3f673a223b029873= a4625dfbd7c74de0430f1fb [2] https://cgit.freebsd.org/ports/commit/Mk/bsd.port.mk?id=3Dab5c91839fead28a4= 6d188b7e895a5a96baad9db --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-280396-7788-68hinJSbE7>