Date: Mon, 22 Jul 2024 09:17:36 +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-nCgiTXPZDq@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 Jason E. Hale <jhale@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhale@FreeBSD.org --- Comment #4 from Jason E. Hale <jhale@FreeBSD.org> --- Created attachment 252220 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D252220&action= =3Dedit POC: Convert USE_C*STD to CMake native In concept, I think this a good idea, but I'm not sold on the execution. For example, your "BROKEN" message is not in the correct place, because it won't apply to any ports that have fortran, noninja or run as arguments passed to USES=3Dcmake. The run argument isn't important in this case, though. Now, I'd be more of a buyer if the "BROKEN=3D" message were converted to a "WARNING+=3D" or "DEV_WARNING+=3D" message since while having conflicting -= std=3D* arguments passed to the compiler isn't exactly ideal, I don't think that warrants automatically marking a port as BROKEN when it has presumably been building just fine prior to this change. Automatically marking ports BROKEN just because they don't strictly conform to a fabricated ideal is, quite frankly, absurd. As a side note: The *WARNING variables, unlike the BROKEN variable, require their contents to be double quoted and very much do not l= ike their contents to contain parentheses (or round brackets if you're a weirdo j/k)...anyways, these things -> (). Now that I'm thinking...instead of marking everything BROKEN, painstakingly iterating through the entire ports tree pounding on countless individual po= rts to make them submit, banishing use of standard bsd.port.mk variables, or potentially adding WARNINGs that could make use of CMake seem even more off-putting than it already is to some, let's take a breather. Refocus. Per= haps we could be a bit more clever and handle this transparently entirely within= the CMake framework. The pseudocode I'm currently thinking about in cmake.mk is this: - Check if USE_C*STD is defined - If so, save the contents of USE_C*STD to a "private" temporary variable - Undefine USE_C*STD, so that it isn't used in bsd.port.mk - Determine the standard and if extensions are needed from that "private" variable - Pass above information to the appropriate CMake variables I've attached an almost not tested proof of concept that doesn't include any error checking, but bsd.port.mk doesn't either with regard to the USE_C*STD variables. For example, if one defines USE_CXXSTD=3Dc++42069 in a port Make= file, that will simply be added to CXXFLAGS with a "-std=3D" slapped in front of = it. Port maintainers and especially committers are expected to know better. Defining this wouldn't pass the configure stage, anyways, at least with CMa= ke. I don't believe my POC would require other changes in the ports tree. To me, this would be much less intrusive and the idea of not being able to use standard bsd.port.mk variables in ports that use CMake just really puts a b= ad taste in my mouth. Open for feedback. --=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-nCgiTXPZDq>