Closed #547 via #1392.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/547#event-3892043975___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
Pulled that part out of #1383 for now to avoid piling on.
In the meanwhile I've been pondering about that '..' syntax which is as
arbitrary as anything. Maybe a better syntax would be a wildcard '*' instead, ie
```
%foo(*) {
}
```
Thoughts?
--
You are receiving this because you commented.
Implemented in PR #1383, but not specific to Lua despite the PR title.
Simply pass '..' as the option string, eg `%foo(..)`. This will skip option
processing in rpm, and any options that a macro might receive are simply passed
as raw string arguments.
--
You are receiving this because you
One possibility might be giving this power only to Lua macros via the native
argument mechanism (ie the proof-of-concept stuff in #1063)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
> Since you asked, here's a small proposal and a possible alternative.
>
> Proposal: In a macro definition, using an argument string of `-` (as in
> `%define macro(-)`) indicates
> that getopt processing should not be done at all, and all supplied arguments
> and options should be
> delivered
@nim-nim, @jasontibbitts okay I see now, thanks for the explanations.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
First: use a macro file, not a %define, to hide abc...XYZ. If you must have
package specific macro overrides, the use %{load:...} and bury the override in
a SourceN: directive. The most important reason to use a macrofile is
readability: you can split a definition over multiple lines, unlike a
What we're trying to get around is having to do `%define
foo(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ)` so that the macro
can just handle parsing `%**` itself, and then still not being able to handle
anything that looks like a long option. That hack allows repeated arguments,
That is indeed the case that some flags are handled by the macro processor,
while others are passed along, when -- is used to stop getopt(3) option
processing.
Long options would need a means to be specified in the macro definition, and
multiple duplicated options, and or arg types, would also
But that exposes to the macro user that some flags are handled by the rpm
argument parser and others by something else.
And that forces the macro user to use a specific flag order.
The macro user does not care about all this – that's a macro implementation
detail
--
You are receiving this
RPM already has support for %(...) shell diversions and %{lua:...} embedding,
both of which are well known programming paradigms that should be used instead
of macros wherever you find your efforts limited by lack of a failure message
from a macro option/argument.
--
You are receiving this
rpm macro argument parsing is ancient and limitating, it can not handle
full-word flags, it can not handle repeated flags, and so on
please add a syntax to specify a macro should not fail when used with a flag
not declared to rpm argument parsing, so all those new forms of arguments can
be
12 matches
Mail list logo
