Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
Very well then. Thanks a lot for fixing all these lose ends I left around! -- 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/1809#issuecomment-951620460___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
Yes, I think this can be merged if you're fine with the changes. -- 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/1809#issuecomment-951084325___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
(Would you prefer us to merge this at this point and continue on the remaining details elsewhere? I'm fine either way.) -- 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/1809#issuecomment-950944552___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
The non-braced syntax does indeed seem more natural for some things and some contexts (eg --eval from cli), I'd hate to outlaw that just because. No objections to allowing multiple arguments to builtins where it makes sense, allowing that was an explicit intention even. -- 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/1809#issuecomment-950873995___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
(force pushed because I added a testcase for the last commit) -- 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/1809#issuecomment-950836702___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
@mlschroe pushed 1 commit. fa3c6df29bfce68ffa24daf56623dd4c3c9ea497 Support non-parametric builtins again -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1809/files/5ede2ac87470251ab263a38cb1da54dc8a54dfe8..fa3c6df29bfce68ffa24daf56623dd4c3c9ea497 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
Heh, talk about weird indeed, gotta be careful with what we want to be consistent with because the '%expand hello world' case doesn't make a whole lot of sense, but then I'm not sure what it should be doing really. Ditto with '%lua foo bar'. If a syntax doesn't make any sense then maybe it'd be best disabled... And yes we shouldn't make this any weirder than it has to be, making built-ins more like normal macros was a big point of the exercise in 4.17, only (painfully obviously :laughing: ) unfinished... -- 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/1809#issuecomment-950786764___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
@mlschroe pushed 1 commit. 5ede2ac87470251ab263a38cb1da54dc8a54dfe8 Support non-parametric builtins again -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1809/files/7aef17192df56af869511b7aaaddbe03ca01897b..5ede2ac87470251ab263a38cb1da54dc8a54dfe8 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
%expand is not ME_PARSE, so it grabs the args till the end of line. It also
does arg splitting and just uses the first arg, which is maybe not what we want:
```
./rpm --eval '%expand hello world'
hello
```
We could disable the arg splitting with some new flag, but I don't think
builtins should be too different to normal macros. People anyway use
`%{macro:arg}` where we do not split.
%lua is somewhat special because we do not want macro expansion to happen at
all.
--
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/1809#issuecomment-950754798___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Refactor parameter handling of builtin macros (PR #1809)
> Should rpm --eval '%lua print("foo")' work? This is pretty trivial to do,
> it's also consistent with the other macros but it's also somewhat weird.
It's a bit weird yes, but no strong opinion, consistency is generally a good
thing though. %expand is the closest thing to %lua I guess, what do we do with
that now? (haven't had a chance to properly look at this all yet)
> Should we make the zero-arg builtins non-parametric? I.e. should 'make -j
> %getncpus all` work? (It used to work with older rpm versions)
Yes, this was really just an unintended side-effect lost in the noise (I didn't
remember we *have* non-parametric built-ins)
--
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/1809#issuecomment-950736856___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
