public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 1/3] libsupport: fix portability issues with the bthread.c
Date: Fri, 3 Apr 2026 17:00:46 -0400	[thread overview]
Message-ID: <20260403210046.GC16311@macsyma-wired.lan> (raw)
In-Reply-To: <20260403151535.GI6254@frogsfrogsfrogs>

On Fri, Apr 03, 2026 at 08:15:35AM -0700, Darrick J. Wong wrote:
> > It's "autoheader".  Whenver you add or remove tests to configure.ac,
> > you need to run "autoconf ; autoheader".  If you don't run
> > "autoheader", then even if the autoconf's feature test enables some
> > new feature test, say HAVE_PR_SET_IO_FLUSHER, the feature won't
> > actually be enabled in the #ifdef.
> 
> Aha!  Thanks for that tip; I'll go fix my dev branch.

Just to give more context, there are two ways that configure scripts
can pass the feature definitions to programs.  One is via the command
line of the compiler.  The problem with that is if you have dozens of
options like -DHAVE_PR_SET_IO_FLUSHER for every single compile, it
bloats the MAKELOG files and makes it hard to read, and eventually you
can run into the command-line length limits.

The other way is via a config.h file which is then #included in each
source file.  But for *that* to work, the config.h.in file needs to
have a template for echo variable that can be #defined.  And that's
what autoheader takes care of for you.  Simpler projects that don't
use a config.h file and pass everything on the compiler's command line
don't need to use autoheader.

For a demonstration, try editing lib/config.h.in to remove the lines:

-/* Define to 1 if PR_SET_IO_FLUSHER is present */
-#undef HAVE_PR_SET_IO_FLUSHER

Then "rm lib/config.h" and run "./config.status", and examine
lib/config.h.  You will see that HAVE_PR_SET_IO_FLUSHER is no longer
defined in the config.h file.  Then run "autoheader", and then re-run
"./config.status", and you will see that HAVE_PR_SET_IO_FLUSHER is
properly defined.

Cheers,

					- Ted

  reply	other threads:[~2026-04-03 21:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-03  4:03 [PATCH -e2fsprogs 0/3] Fix portability issues on MacOS Theodore Ts'o
2026-04-03  4:03 ` [PATCH 1/3] libsupport: fix portability issues with the bthread.c Theodore Ts'o
2026-04-03  4:16   ` Darrick J. Wong
2026-04-03 11:53     ` Theodore Tso
2026-04-03 15:15       ` Darrick J. Wong
2026-04-03 21:00         ` Theodore Tso [this message]
2026-04-03  4:03 ` [PATCH 2/3] libsupport: add a portable get_thread_id() function Theodore Ts'o
2026-04-03  4:17   ` Darrick J. Wong
2026-04-03  4:03 ` [PATCH 3/3] fuse2fs: fix build failure on systems which don't define EUCLEAN Theodore Ts'o
2026-04-03  4:18   ` Darrick J. Wong

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260403210046.GC16311@macsyma-wired.lan \
    --to=tytso@mit.edu \
    --cc=djwong@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /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