From: Bruno Haible <bruno@clisp.org>
To: Gavin Smith <GavinSmith0123@gmail.com>,
Paul Eggert <eggert@cs.ucla.edu>,
bug-gnulib@gnu.org
Subject: Re: Avoid gnulib redefinitions - free-posix
Date: Sun, 30 Oct 2022 14:37:59 +0100 [thread overview]
Message-ID: <9529082.q1WVWOPYzV@nimes> (raw)
In-Reply-To: <Y112x4F1hoMHhKU/@starmint>
[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
next prev parent reply other threads:[~2022-10-30 13:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-29 13:36 Avoid gnulib redefinitions - MDA, free-posix Gavin Smith
2022-10-29 16:58 ` Paul Eggert
2022-10-29 18:53 ` Gavin Smith
2022-10-30 13:37 ` Bruno Haible [this message]
2022-10-29 21:48 ` Avoid gnulib redefinitions - MDA Bruno Haible
2022-10-29 21:59 ` Gavin Smith
2022-10-29 22:09 ` Bruno Haible
2022-10-29 22:20 ` Gavin Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9529082.q1WVWOPYzV@nimes \
--to=bruno@clisp.org \
--cc=GavinSmith0123@gmail.com \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).