>>>> "JC" == Japheth Cleaver
JC> I'd say that will *probably* be the case and could be a safe option,
JC> but %configure could always have more actions added to it.
More autotools-related actions, sure, but that wouldn't be relevant to
what you're proposing because you're explicitly referencing the case
where autotools isn't used.
JC> Since if we run make, we're running an arbitrary
JC> Makefile... future-proofing might be good.
I don't understand how future-proofing comes into this. Seems more
logical that you would avoid using %configure when autotools isn't in
use because it would potentially assume that autotools is actually in
use. Avoiding the use of something in situations where it's explicitly
not intended to be used seems much more future-proof to me.
JC> %configure is also an omnipresent macro that anyone w/ even a basic
JC> understanding of specs will grok,
%configure is certainly present in packages which use autotools; I won't
argue that. It's definitely not present the vast majority of packages.
Not most rust or go or python or perl or nodejs packages. Not in
packages which use, say, meson or cmake as the build system. That really
doesn't seem to me to rise to the level of "omnipresent".
JC> while %set_build_flags is a bit more obscure.
%set_build_flags is simply the intended way to accomplish what you're
trying to accomplish. Adding a rather obscure creation of a fake
configure script just so you can use another macro that you find less
obscure doesn't feel like it's doing much in the way of reducing