Add support for macro aliases #2722
Conversation
|
My immediate use-case for this will be in #2620 but I remember missing such functionality for at least one other purpose. And who knows what fun the packaging community comes up with... |
pmatilai
force-pushed
the
macroalias-pr
branch
from
9d08fee to
ae954c8
Compare
|
Added more elaborate documentation. In order to document the aliases I needed to document all sorts of other macro behavior first, which is not a bad thing... |
pmatilai
force-pushed
the
macroalias-pr
branch
from
1434a4e to
3a404fe
Compare
The assignment combined with \0 check makes it look more complicated than it is. We don't need to specifically check for the \0 here because it'll fail all the other tests anyhow. Use a char point instead of int because this will make next commit nicer.
For existing usages this makes little difference because %define and %global error out with "needs whitespace before body" in case of illegal names due to the way the name and options are parsed (should fix this one day...). We'll need this in the next commit though.
Implement support for multi-level macro aliases, useful for the kind of thing aliases are: shortcuts, added level of indirection here and there for eg choosing between alternatives without copying and so on. The new %alias macro primitive can be used to define an alias and get the alias definition. The dual functionality is necessary because all other references to the alias get routed to the aliased macro. With the exception of undefine which undefines the alias itself.
Explaining aliases needs context that we were missing before.
pmatilai
force-pushed
the
macroalias-pr
branch
from
3a404fe to
27d0776
Compare
|
Rebase on top of the other recent stuff. |
|
I am still a bit puzzled on what this can do that you can't do with a simple macro definition. I mean I have a rough idea. But may be the docs should make a bit more of an effort to explain what to use in which case. |
|
It should be more obvious once I rebase the autobuild thing on top of this all, but maybe it helps to think of aliases as a means to achieve "alternatives" in the macro space. In the autobuild context, we have these __foo_build, __bar_build, __zap_build etc macros defined for various different buildsystems. Those are all usable in standalone format by calling the explicit lengthy name, but when one uses Autobuild: tag, there should be a shortcut to the active build type, eg in the spec you only then need to use %autobuild_build / %autobuild_install etc if you manually need to invoke it for whatever reason. That should also simplify the rpm implementation side of the autobuild a bit. And you can't really achieve this (parametric macro semantics and all) with regular macro definitions. One could make a copy I suppose, but we don't have support for that either, and it wouldn't be quite the same. |
|
Hmm, of course this would be far more powerful if it supported arguments and all, similar to eg bash aliases. |
|
This will need at least a C API for adding aliases. And maybe look at the bash-style alias thing too. |
|
Withdrawing for now. |
Implement support for multi-level macro aliases, useful for the kind of thing aliases are: shortcuts, added level of indirection here and there for eg choosing between alternatives without copying and so on.
The new %alias macro primitive can be used to define an alias and get the alias definition. The dual functionality is necessary because all other references to the alias get routed to the aliased macro. With the exception of undefine which undefines the alias itself.