tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/www/c-icap



Greg Troxel wrote:
> "Nia Alarie" <nia%netbsd.org@localhost> 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


Home | Main Index | Thread Index | Old Index