Re: CVS commit: pkgsrc/www/c-icap
Michael Bäuerle <[email protected]> Mon, 15 Jun 2026 12:29:04 +0200
| Newsgroups | gmane.os.netbsd.devel.packages |
|---|---|
| Message-ID | <[email protected]> |
Greg Troxel wrote: > "Nia Alarie" <[email protected]> writes: > > > > Log Message: > > c-icap: Fails with C23 default language. > > > -USE_LANGUAGES= c > > +FORCE_C_STD= gnu89 > > (I didn't comment on the first one, but this now seems like a > larger-scale change.) > > It seems the root cause is compilers defaulting to a newer std. That > seems obviously buggy but not something we can address. > > Given how compilers are, a package failing to probe for and set --std is > an upstream bug. I don't agree. "--std" is not supported by all C compilers, e.g. the POSIX C compiler use its name to select the language ("c99" or c17"). Probing for nonstandard or undocumented options looks error prone. If the package does not use GNU autotools, CMake or meson, it may be an enormous amount of work to implement such probing for little benefit (it will cover only a few compilers known to the author). I would expect it to work only with mainstream compilers like GCC and Clang. I think the job of the author is to document what language (version) is required. And it is the job of the user (not the build system) to prepare an environment that provides a suitable compiler and suitable flags for it. pkgsrc supports multiple compilers and its infrastructure would be a good place to switch the mode (instead of doing it in the build systems again and again -- likely wrong every time for non-mainstream compilers). PS: My comments above are for C. Things are different for C++, because it may not work to link objects together, if they are compiled for different versions. -- Regards, Michael