On 01 Dec 2023 17:39, Nick Bowler wrote: > On 2023-12-01 15:37, Jan Engelhardt wrote: > > On Friday 2023-12-01 21:13, Mike Frysinger wrote: > >> On 17 Jul 2023 16:51, Karl Berry wrote: > >>> Hi Jan, > >>> > >>> Current automake likely won't have anything in store already, > >>> > >>> Not that I know of. > >>> > >>> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c) > >>> > >>> I've often wanted this myself. I'd certainly welcome a patch for it. > >>> > >>> Please work from automake trunk. None of the various branches are kept > >>> to date. (Sad but that's the reality.) > >> > >> prob stating the obvious, but $(addprefix) is a GNUism, so if we wanted to > >> use it, it'd required feature probing at configure time, and that always > >> complicates things :( > > > > No-no, the idea was to make $(addprefix) an automakeism that is resolved > > before > > GNU make (or any other make) is ever invoked. > > I suggest inventing a new syntax if this approach is taken, one that > doesn't overload real-world make syntax, since some people do use > Automake with GNU-make-specific rules and whatnot. We already have > things like %reldir% which are expanded by Automake so maybe using > percent signs as a marker for "things expanded by automake" would > be a good starting point for this. > > I do sometimes wish Automake had more built-in macro facilities. > One can do things like generate includeable snippets or preprocess > Makefile.am with, say, m4, but that adds a bunch of additional > complexity which is not always worthwhile.
we're already blurring the lines by processing things like `if`. it also has the benefit of not having to learn more automake-only DSLs like the %var% syntax. imo it's ok to preprocess things that can be statically done like $(addprefix). -mike
signature.asc
Description: PGP signature
