bug-gnulib
[Top][All Lists]
Advanced

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

Re: Avoid gnulib redefinitions - free-posix


From: Bruno Haible
Subject: Re: Avoid gnulib redefinitions - free-posix
Date: Sun, 30 Oct 2022 14:37:59 +0100

[Removing bug-texinfo from the CC.]

Gavin Smith wrote:
> This avoided looking through all the gnulib code and deciding where
> to replace "free" with "gl_internal_free" or whatever the replacement
> would be called.

Yes, this would not be maintainable. Also because some Gnulib code
is shared with glibc, and we want to keep using 'free' in these files.

> The main idea is to put a define in AM_CPPFLAGS in the Makefile that
> gnulib-tool generates.  Then the gnulib headers can distinguish whether
> they are being used as part of building gnulib, or building the user's
> program.

That's an interesting implementation idea. And it readily generalizes to
other modules, via the "module indicator macro" that we define in
gnulib-common.m4 lines 529..619.

> Let me know if this is the right approach and if there are changes to
> make to the patch.

I'll try to come up with a patch that
  - works for other modules too,
  - requires a gnulib-tool option to be activated. Your patch changes the
    behaviour of Gnulib unconditionally, which would cause problems in
    other packages.

I'm currently thinking to call this gnulib-tool option
  --hide-decls=free-posix
but I'd like to have a better option name than that.

Also, I'm thinking about an option --hide-all-decls, that would be like
--hide-decls for all modules of the transitive closure that were *not*
specified on the command line. That would be a very different way of
using Gnulib, where the package maintainer would be forced to explicitly
enumerate the modules for which they want to see the declarations in their
code. Hmm, maybe that's too radical...

Bruno






reply via email to

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