From: Alejandro Colomar <alx@kernel.org>
To: Ingo Schwarze <schwarze@usta.de>
Cc: linux-man@vger.kernel.org
Subject: Re: configure separate from make or not
Date: Sun, 30 Aug 2026 15:17:07 +0200 [thread overview]
Message-ID: <apQq4u6L8i3Ax_DA@devuan> (raw)
In-Reply-To: <apMytOcLd3pecFFc@devuan>
[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]
Hi Ingo,
> Date: 2026-08-29 22:49:08+0200
> From: Alejandro Colomar <alx@kernel.org>
>
[...]
>
> The main thing I run code for in the makefiles is for listing all the
> source files. Here's an example:
>
> $ grepc -xmk -tv -n MANPAGES share/mk/
> share/mk/src/man.mk:20:MANPAGES ::= $(shell $(FIND) $(MANDIR)/* -type f \
> | $(GREP) -E '$(MANEXT)' \
> | $(SORTMAN) \
> | $(SED) 's,:,\\:,g')
>
> I know you prefer to list them manually, but I like this little bit
> of magic (it's not that magic, since it's written in the code, but
> admittedly, if you're not used to this build system, it's hard to
> expect it).
BTW, the git repository is tracking 3387 files (at the moment, and
growing), and thus the distribution tarball contains that many files.
Given this amount of files, I find it more maintainable using scripts
instead of hard-coded lists. I could have a hard-coded list, and
regularly diff it with the output of find(1), but I prefer using find(1)
directly in the makefiles. Also, I wouldn't want to have 80k of
Makefile text that is the output of a command:
$ git ls-files | wc -c
80511
We already have quite heavy makefiles, at around 100k, and that would
duplicate their size.
[...]
> The thing is, we have 1.5k non-link pages, and we use absolute paths
> in most variables. Thus, each variable can hold around 100kB for the
> paths:
>
> $ find man/ -type f | xargs grep -l '^\.TH' | xargs realpath | wc -c
> 106833
>
> 'make help-list-targets' lists 119 .PHONY targets, of which most require
> at least one variable for holding the actual file targets. A simple
> multiplication and rounding says there's 100x100k = 10M in these path
> variables. Then 25 MB sounds not far from that.
>
> I think I might be able to optimize this down by using relative paths.
> I might be able to optimize this a bit further by using suffix rules
> as much as possible, instead of listing all targets in the rules again.
> But there's a hard floor. It should be hard to go much below current
> size, at least without reducing targets.
Self-correction: we're not using absolute paths; they're relative.
It seems I had already implemented this optimization, and I didn't
remember. Anyway, relative paths don't change much. The best gain
would come from using suffix rules, which would save a few variables
entirely.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-08-30 13:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 19:21 [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config DJ Delorie
2026-08-06 14:37 ` Alejandro Colomar
2026-08-06 15:33 ` DJ Delorie
2026-08-06 19:14 ` Alejandro Colomar
2026-08-06 20:17 ` DJ Delorie
2026-08-06 20:31 ` Alejandro Colomar
2026-08-06 20:42 ` DJ Delorie
2026-08-07 2:12 ` G. Branden Robinson
2026-08-07 3:29 ` DJ Delorie
2026-08-07 3:49 ` G. Branden Robinson
2026-08-07 4:01 ` DJ Delorie
2026-08-07 4:09 ` G. Branden Robinson
2026-08-23 12:29 ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-23 13:27 ` G. Branden Robinson
2026-08-23 13:55 ` Alejandro Colomar
2026-08-23 14:16 ` G. Branden Robinson
2026-08-23 15:06 ` Alejandro Colomar
2026-08-23 16:44 ` G. Branden Robinson
2026-08-23 19:30 ` Alejandro Colomar
2026-08-23 20:40 ` G. Branden Robinson
2026-08-23 23:11 ` Alejandro Colomar
2026-08-24 1:11 ` G. Branden Robinson
2026-08-24 2:01 ` Using LS/LE Collin Funk
2026-08-24 11:08 ` Alejandro Colomar
2026-08-24 11:00 ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-23 22:31 ` autotools, was: Using LS/LE Ingo Schwarze
2026-08-24 0:09 ` Alejandro Colomar
2026-08-29 4:36 ` G. Branden Robinson
2026-08-29 11:34 ` Ingo Schwarze
2026-08-29 12:51 ` Alejandro Colomar
2026-08-29 19:16 ` G. Branden Robinson
2026-08-29 21:43 ` Alejandro Colomar
[not found] ` <8DE76435-CBDB-42D6-9E0F-9E27291560B6@icloud.com>
2026-08-29 8:42 ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-29 8:45 ` Alejandro Colomar
2026-08-29 8:52 ` Alejandro Colomar
2026-08-29 9:02 ` Alejandro Colomar
2026-08-29 9:39 ` Ingo Schwarze
2026-08-29 13:10 ` configure separate from make or not (was: Using LS/LE) Alejandro Colomar
2026-08-29 15:31 ` configure separate from make or not Ingo Schwarze
2026-08-29 20:49 ` Alejandro Colomar
2026-08-30 13:17 ` Alejandro Colomar [this message]
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=apQq4u6L8i3Ax_DA@devuan \
--to=alx@kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=schwarze@usta.de \
/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