Expand parametric macro arguments before processing (#127, RhBug:1397209)
This too is quite a fundamental change for macros: up to now, arguments to parametric macros have not been expanded. It doesn't sound so bad until you consider something like the case in RhBug:1397209: %global rev 133 ... %setup %{?rev:-c} %autosetup %{?rev:-c} One would expect %setup and %autosetup behave the same when you replace one with the other, but no. %setup gets "called" with -c, %autosetup does not. Instead %autosetup receives a completely useless, literal "%{?rev:-c}" as its argument. That's just brain-meltingly non-sensical. This certainly has the potential to break advanced macro constructs, but OTOH what breaks might well be only written that way in order to work around the former behavior. There are some funny subtleties involved as the argument expansion must occur in the callers scope, ie before we create any of the automatic macros. For example, Fedora's font packages break if only this or the macro scope visibility enforcement is applied but start working again once both are present.
This commit is contained in:
parent
307627993e
commit
5adc56897b
|
@ -675,9 +675,10 @@ grabArgs(MacroBuf mb, const rpmMacroEntry me, const char * se,
|
|||
argvAdd(&argv, me->name);
|
||||
if (lastc) {
|
||||
ARGV_t av = NULL;
|
||||
char *s = xcalloc((lastc-se)+1, sizeof(*s));
|
||||
memcpy(s, se, (lastc-se));
|
||||
char *s = NULL;
|
||||
|
||||
/* Expand possible macros in arguments */
|
||||
expandThis(mb, se, lastc-se, &s);
|
||||
argvSplit(&av, s, " \t");
|
||||
argvAppend(&argv, av);
|
||||
|
||||
|
|
Loading…
Reference in New Issue