If you are going to add a hard wired validation table for builtin macros, then
you might as well use the same table for dispatching during macro expansion.
Possibly better would be to add a builtin flag to defined macros and treat as
all other macros are treated, thereby permitting builtin
For extra credit: The line number (and the current type of definition like
RMIL_MACROFILES) might reasonably be attached to each macro definition, perhaps
by masking to avoid changing rpmDefine() in the API.
Otherwise add additional int arguments to rpmDefine()
--
You are receiving this
Abusing the negative level macro definition as an index into files from which
definitions were read, with an associated file name table, as well as the
modest change to display the file name(s) where macros are defined, is likely
more useful than detecting errors while loading/defining a macro.
Well it only differs in that case if you have a file with an invalid macro and
add another which is not invalid. At which point a useless file becomes at
least partially useful.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Anyway, thanks for the fixes, the "This alternatively" has annoyed me too for a
long time but I never remembered to fix it :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #380.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/380#event-1415197317___
Rpm-maint mailing list
Licenses cover more than just the source. If you think about the main
difference between GPL and LGPL (which incidentally happens to be the licenses
at hand)? The latter permits more liberal linking against the *compiled
library* of the software licensed under it. No source involved. Not to
