>>>>> "JC" == Japheth Cleaver <cleaver@xxxxxxxxxxxxxx> writes: 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 obscurity. - J< _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
