Linux Manual Pages development
 help / color / mirror / Atom feed
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 --]

      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