"total" equals calling with no arguments, "proc" and "thread" consider
further constraints, what is implemented here is heuristics based on
available physical memory and address-space and %_smp_tasksize_proc /
%_smp_tasksize_thread tunables.
Change the previous %getncpus related tests to use %getconfdir instead,
they are testing unexpected arguments behavior for this type of macro,
not %getncpus itself. Add a test for the actual functionality: if nproc
is available, test that our total matches with that, and that defining
tasksize to total memory only allocates one thread. Optimally we'd
test separately for 32bit address space limitations but that gets tough
when we have no idea where this will be executed.
This is the same issue as commit 1767bc4fd8
was with Lua, and so the same fix works: restore the nesting level
from the macro context when re-entering macro engine from %[]
expression. Analysis and suggested fix by Michael Schroeder,
reproducer from Miro Hrončok.
Add tests for both %[] and %{expr:...}, although the latter isn't
affected because the expression is macro-expanded beforehand.
Fixes: #2354
Despite all the Lua magic we already do, it's annoyingly often the case
that shelling out is easier (or at least shorter) than doing the same in
Lua (substrings, length etc)
Add shorthand macros %gsub, %len, %lower, %rep, %reverse, %sub and
%upper which simply wrap the corresponding Lua string.* functions for
convenience.
This means that finally there's just one place that when adding support
for new compress formats, there's in theory there's just one place to
update. Reality is a little more complicated, but hey...
Adjust tests a bit, and rather test functionality than command output
because those reflect command paths which we can't easily adjust now.
This improves compatibility with old rpm versions. If an argument
is present, the macro expands to it in verbose mode and to an
empty string if not in verbose mode.
Macros like %getncpus should not treat the following text as
macro arguments. E.g. 'make -j %getncpus all' should work and
not complain about an unexpected argument.
We still treat arguments passed via %{foo:arg} or %{foo arg} as an
error for builtin macros. (They are silently ignored for user
defined macros.)
This means no special new line processing and '\' unescaping. Thus
"%{define foo body}" works similar to "%define foo {body}" except
that the parsing in spec files works because copyNextLineFromOFI()
knows how to deal with macros.
doXXX() used to return the parsed characters for ME_PARSE macros
and the caller added them to the "parsed" variable.
We now directly pass parsed as argument and let the doXXX()
functions do the adding. This will allow us to differentiate
between "%define foo bar" and "%{define foo bar}" in a
future commit.
No functual changes.
The builtin macros used to expand the arguments themselfs. This
works for the %{foo:bar} syntax, but it means that for %{foo bar}
the argument is expanded twice: once before the argument is split
and then in the macro function.
Simplify the code by always doing the expansion when creating
the argument vector.
Realizing that we have dynamic string buffer available in the macro
engine... so we don't need a dumb worst case malloc and all the other
crap in the old tag format era implementation.
All current automatic macros are named in a way that do not pass the
name check in validName(), but that's kinda implicit. Specifically
test for ME_AUTO along with ME_BUILTIN.
No functional change due to the implicit protection from the naming.
Traditionally rpm has required user defined macro names to be at least
three characters long, but outlaws all sorts of useful names like %cc
for no particularly good reason - on unix a *lot* of commands are two
characters, and then there are programming languages named R and whatnot.
For macros starting with underscore, require one additional character
though so `r` is okay and so is `_r` but plain `_` is not.
The name validation and error reporting is buggy in multiple ways but not
in the mood to chase all those now, this is just the bare minimum change.
Previously %{ and similar in macro file comment line would cause the
line continuation logic to trigger and silently eat macro definitions
up to the next empty line. Since 75275a87cf
we permit empty lines inside macro definitions, which would cause the
whole remaining file to be silently skipped (RhBug:1953910)
Only ever parse macro file lines starting with %, and add a test for
the case.
Actual patch by Michael Schroeder, testcase by undersigned.
Fixes: #1659
The old logic always finished adding lines if an empty line
was encountered, because the check that should guard against
accessing outside of the read buffer was done at the wrong
level.
Also simplify the code by letting 'q' point to the new line and
not before the newline, which also fixes potential undefined
behaviour.
Also get rid of the unused 'nread' variable.
More and more macros, scriptlets and other functionality has been getting
built around Lua, to the point that it has in practice been required for
several years now.
Maintaining the pretense of being optional comes at a cost in holding
back developments and having to check for that theoretical special
case. Lets make it a hard requirement and embrace it some more!
Only dump out macro tracebacks in verbose mode, which incidentally
rpmbuild normally runs in.
Sadly our tracebacks are not as useful as they could be, but improving
that is a separate topic...
The rationale behind the change was to suppress the excessive output
when trying to expand a recursive macro definition (RhBug:613010) but
this is not so good as it effectively suppresses *all* backtrace output,
include those requested by %trace where the other half is printed to
stderr and the other half in the debug log because of the change.
Besides making things consistent, this also avoids deadlock on
`rpm -vv --eval '%trace'`.
This reverts commit 7f220202f2.
Fixes: #1418
doDefine() wants macro file-style "name body" string as an argument, but
when called through rpmExpandThisMacro() you'd expect to put the name
and body in separate arguments. Properly handling this in the macro engine
guts is more than I'm prepared to do at the moment, but we can detect
the multiple arguments case and turn the arguments into something that
doDefine groks.
This will matter when we add support for calling macros as native Lua
elements.
%dump macro takes no arguments of any kind, it just eats the rest of
the line which doesn't make any sense whatsoever. So while this
theoretically changes %dump behavior, the behavior actually changed
a few commits back with the calling syntax unification: %dump never
took actual arguments, so it'll now just error out if there's text
on the same line where it previously ignored that. Unless you use
%{dump} that is.
%undefine parsing its own argument makes no sense whatsoever,
it's just a name and nothing special. Now that the calling syntax
is no longer an issue, make it sane. No functional changes.
No functional changes here, but going forward this gives us more
flexibility than the ME_HAVEARG. We could also extend this to support
mandatory arguments to user defined macros too.
Now that both types use identical function signature, we can trivially
unify the calling code for both, simplifying things somewhat, make
the non-braced syntax for built-in macros work, and regain type safety.
No functional changes here and not sure if/how these would ever take
multiple arguments, but there's another treasure at the end of
this particular rainbow...
Accept both %{foo:arg} and %{foo arg} notation for both builtins
and user-defined parametric macros, the former only ever has one
argument whereas the latter can have multiple.
"parse" type builtins such as %define are trickier and only work with
traditional syntax for now.
Only define builtin %{lua:...} if actually compiled with the support.
This loses the "informative" error message about the situation but
I think ability to test feature presence is more useful and important.
%{load:...} supported strange conditional syntaxes that conflict
with general macro syntax. Drop support for these undocumented
variants, people can use %{exists:...} to test for file existence
before trying to load a macro file.
%{verbose:...} supported a special syntax of negation with %{!verbose}
but this conflicts with general macro syntax. Now that we have
expressions we can easily handle arbitrary conditions using generic
syntax but %verbose semantics need to change for that: lose the argument
and just return a simple boolean reflecting whether rpm is in verbose
mode or not.
This is obviously an incompatible change, but few things outside rpm itself
should care about this anyhow.
Update the sole user (build scriptlets) to use an expression instead
(whee, the first actual in-tree user!), documentation and testcases
accordingly.
No intended functional changes, but it's one argument less to pass
around, brings builtins one step closer to how user defined
macros are called and is a step towards supporting options to
builtins as well.
Panu Matilainen