So thanks to @mlschroe , we now have much more than originally bargained for.
See
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/macros#L238
for docs and
https://github.com/rpm-software-management/rpm/blob/796104e68a0a4b2e60f8e9b47293055a3159a8eb/tests/rpmmacro.at#L248
Closed #115.
--
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/issues/115#event-2653856761___
Rpm-maint mailing list
I do not see any problem in the syntax that @pmatilai proposed in his previous
comment:
```%{()?:}```
There are two similar options that are closer to the currently proposed triple
condition operator syntax (#746):
```%{{}?:}```
```%{{}::}```
Using these syntax the example from the previous
Support for ? :in the expression parser has the addition bonus that it resolves
the "whitespace stripping" discussion:
```
%{expr: 0%?_include_minidebuginfo ? "mini:true" : "mini:false" }
```
Also note that the expr parser already has a (somewhat insane) macro expansion
feature:
```
%{expr:
My general idea has been that %{expr:...} is strictly for evaluating
expressions into strings, and that a different syntax would be used for boolean
evaluation, something along the lines of
```%{()?:}``` but haven't given the syntax details too much
thought.
Adding support for ```? :```in the
OTOH we could add a `? :` operator to rpm's expression parser:
```
%{expr:%_include_minidebuginfo?"mini:true":"mini:false"}
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Just to start the discussion, I wonder if support for `%{expr:?}`
and
`%{expr:?:}` is too insane? If `//`
contains a '?' or ':' char you could use `%{quote:}` as workaround. E.g.:
```
%{expr:%_include_minidebuginfo?%{quote:mini:true}:%{quote:mini:false}}
```
--
You are receiving this because
To elaborate a bit further... so what rpm really needs, much more than the
triple-operator for existence, is a macro syntax that supports the generic form:
```
? [: ]
```
is an arbitrary expression evaluated by rpmExprBool() (ie the same
as spec %if), is output when expression is true,
I thought the potential gains from ability of testing arbitrary expressions
instead of simple macro existence would be obvious enough not to need
explanations.
The most basic case is that there's tonne of functionality in rpm which uses
macro existence test to determine whether something is
> While we're thinking about extending the conditional macro syntax, here's
> another thing to consider:
> The current ? test is only for (non-)existence of macro, which is extremely
> limiting. We could easily make the spec %if expression parser available to
> macro engine, which would give a
> Another thing is that this syntax makes it impossible to have colons (':') in
> the output (eg '%{!?foo::}'), which is a limitation the original syntax
> doesn't have'. It obviously has it's own set of limitations and quirks...
Not impossible, but not straightforward. For ':' in the output
PR #817 adds support for arbitrary expression parsing in macros. The real power
would come from wedding that to macro conditionals, and that's the thing I want
to see at least *planned for* before we add any new condition syntaxes.
--
You are receiving this because you are subscribed to this
Another thing is that this syntax makes it impossible to have colons (':') in
the output (eg '%{!?foo::}'), which is a limitation the original syntax doesn't
have'. It obviously has it's own set of limitations and quirks...
--
You are receiving this because you are subscribed to this thread.
While we're thinking about extending the conditional macro syntax, here's
another thing to consider:
The current ? test is only for (non-)existence of macro, which is extremely
limiting. We could easily make the spec %if expression parser available to
macro engine, which would give a whole new
Given the proposed syntax, which looks ugly in all cases, I'd prefer to forget
about the ternary operator in RPM and focus on other important issues of RPM.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You are correct %{?:condition:true:false} and %{?!:condition:false:true} also
should not conflict with the current macro usage. I am OK with this notation
too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Bike shedding: I'd prefer `%{?:condition:true:false}` and
`%{?!:condition:false:true}` which also should not conflict with current macro
usage.
Or `%{?condition?true:false}` if we're sure that `?` cannot be in a macro name.
--
You are receiving this because you are subscribed to this thread.
Notation
%{?{condition}:true:false}
%{!?{condition}:false:true}
looks promising for me.
1) It is because it causes no problems in old macros.
2) It looks quite naturaly, the only difference from the most expected notation
are curly baces around the condition. (They are added to reach
An old macro could just as legally and likely contain standalone { } characters
as it can contain !'es, I don't see that as being any safer really.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thinking about it some more... Syntax:
%{?condition:{true}!{false}}
%{!?condition:{false}!{true}}
is OK. So if it is acceptable, I will make a patch for it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I do not see any possibility how to define sensible syntax of the triple
operator, without possible causing problems for macros %{?condition:true} and
%{!?condition:false}. Thus I think that adding this macro without additional
changes is not a good idea.
The syntax of the macro should start
Yup, a ternary operator for macro conditionals would be really handy. No strong
opinion on the separator character. Other than noting how unfortunate it is
that rpm used a syntax that is incompatible with the rest of the world :(
--
You are receiving this because you are subscribed to this
22 matches
Mail list logo
