bug-gnulib
[Top][All Lists]
Advanced

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

Re: Some more <config.h> reminders


From: Bruno Haible
Subject: Re: Some more <config.h> reminders
Date: Fri, 14 Apr 2023 00:18:47 +0200

Hi Paul,

> >  /* This file uses _GL_INLINE_HEADER_BEGIN, _GL_INLINE, 
> > _GL_ATTRIBUTE_ALLOC_SIZE,
> > -   _GL_ATTRIBUTE_MALLOC, _GL_ATTRIBUTE_RETURNS_NONNULL.  */
> > +   _GL_ATTRIBUTE_MALLOC, _GL_ATTRIBUTE_RETURNS_NONNULL, 
> > HAVE_POSIX_MEMALIGN.  */
> >  #if !_GL_CONFIG_H_INCLUDED
> 
> At some point it might be better to omit those comments as bitrot is 
> likely to set in as code evolves but comments don't.
> 
> If we just put the "Please include config.h first." stuff at the start 
> of all public .h files, that'd be easier to maintain and would likely 
> encourage slightly better usage anyway.

I slightly disagree:

  * The bitrot will happen, but is harmless since it's only in comments.

  * I wish to avoid to break applications without good need. If a package
    includes a .h file from Gnulib that does not use anything from
    config.h — there are about 300 such .h files —, and it compiled fine
    so far, and with the added <config.h> reminder it would fail to
    compile. If this package's maintainer complains, what would we tell
    him? That it's a bit easier to maintain for us this way?

It doesn't bother me much if some people call Gnulib a "cursed component" [1],
because we have technical justifications for doing the things like we do
in Gnulib. And by breaking backward compatibility occasionally (as
documented in the NEWS file) we request some time investment from the
package maintainers, to keep up-to-date with gnulib changes. But I don't
think we should take this good-will as granted and cause trouble to our
users when the benefit for us is really small.

Bruno

[1] https://chimera-linux.org/docs/faq






reply via email to

[Prev in Thread] Current Thread [Next in Thread]