Merged #817 into master.
--
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/817#event-2572929323___
Rpm-maint mailing list
Rpm-maint
At the risk of setting precedent that makes users expect friendly error
messages from rpm, I'll keep it. It's just a cosmetical thing in any case and
can be removed without other risk or harm if it turns out to be overly
problematic.
--
You are receiving this because you are subscribed to this
Yes, but usually it is better to know the limitations of the current solution
before it is merged.
I prefer to rip the marker support. But you can choose whether rip it or not.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, I'm sure you can construct arbitrary cases where it's not going to point
to the right place.
Making the expression error reports *perfect* is not in the scope of this PR,
so either I rip the marker support out or we leave it the way it is.
--
You are receiving this because you are subscrib
It is definitely better.
I tried a multiline expression:
```
rpm --eval '%{expr: 0 || 0 ||
0 || 0 |o| 0}'
```
and **'^'** does not point to the expected position:
```
+error: syntax error while parsing ||: 0 || 0 ||
+ 0 || 0 |o| 0
+error:
And now with improved expression error messages in both specs and macros.
--
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/817#issuecomment-523410815_
> The error messages are simply the same as you get from spec %if conditionals,
> there are no messages added / changed in this PR. That's not to say the
> messages couldn't maybe be improved, but any change needs to account for the
> fact that they're shared between two quite different contexts
Oh and BTW, the reason for doing this *just now* is that it might be kinda
necessary for resolving #804 in the macro space instead of placing all the
calculations on the C side. Of course technically Lua could be used for those
same calculations but we I don't want to make Lua a hard dependency.
The error messages are simply the same as you get from spec %if conditionals,
there are no messages added / changed in this PR. That's not to say the
messages couldn't maybe be improved, but any change needs to account for the
fact that they're shared between two quite different contexts.
There
@pmatilai pushed 1 commit.
22331d303765509f1856352713a8a4de74b1085e Add %{expr:...} macro for parsing
expressions
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/817/files/0efdee6fec3848bfd3a4ccf160df5
Functionality is OK, but error messages can be improved. I tried macros:
%{expr:0 || b} %{expr:4 &|| 0} %{expr:6 + 9 - o -=iu}
in a spec file and error messages were:
error: types must match
error: syntax error while parsing &&
error: types must match
--
You are receiving this because y
Forgot to update POTFILES.in. Thank you distcheck for catching it early...
--
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/817#issuecomment-521558880
Supports the same expressions as spec %if conditions because, only this returns
the result as a string instead of a boolean.
This obviously *screams* to be wired into macro conditional syntax, but that's
left as an exercise for later.
You can view, comment on, or merge this pull request online a
13 matches
Mail list logo