[Bug 280396] Mk/Uses/cmake.mk: Disallow USE_CSTD and USE_CXXSTD
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 280396] Mk/Uses/cmake.mk: Disallow USE_CSTD and USE_CXXSTD"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 26 Jul 2024 04:26:17 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280396 --- 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 struggling with remembering "common" helpers/macros and I don't think we need 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] years 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 such is a weak argument. Even the ports(7) manpage admits that the spread-out nature 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 basic 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 porter. 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 being a bit strict in this case as it makes overall maintaince easier, more consistent than having multiple ways to approach the same issue in. Who's maintenance time is being enhanced by converting standard ports variables 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 use slashes (/) or commas (,). [1] https://cgit.freebsd.org/ports/commit/Mk/bsd.port.mk?id=c3f673a223b029873a4625dfbd7c74de0430f1fb [2] https://cgit.freebsd.org/ports/commit/Mk/bsd.port.mk?id=ab5c91839fead28a46d188b7e895a5a96baad9db -- You are receiving this mail because: You are on the CC list for the bug.