Yeah, it feels weird.
--
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/304#issuecomment-323503177___
Rpm-maint mailing list
I don't think we need to run any checks on python/shell code... Although we do
run static analyser from time to time locally.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mattdm wrote:
> In these days of version control, I think we've outlived the usefulness of
> having full changelogs in RPM files. Yet, it's still useful to have them in
> the specfile for workflows and build systems which haven't adapted to using
> version control changelogs.
This is
Um ... its not that simple, and the idea of mapping out changelings to a file
that is then retrofitted to "rpm --changelog" pretends to a silly legacy
compatibility (and adds complexity for not much gain other than not having to
justify the change).
You are more than a little late to the
I want to add `make style-check` task for static code analysis as a dependency
task of `make check` in `Makefile`. Because it helps to maintain, keeping the
code clean.
Candidate tools
- C file: I do not know which tool is good.
- Python file: `flake8` [1].
- Shell (bash) file: `sh -n`,
I would close this PR to change the approach.
--
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/303#issuecomment-323445795___
Closed #303.
--
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/303#event-1212471133___
Rpm-maint mailing list
In these days of version control, I think we've outlived the usefulness of
having full changelogs in RPM files. Yet, it's still useful to have them in the
specfile for workflows and build systems which haven't adapted to using version
control changelogs.
My suggestion is:
1. Changelog entries
Yup, that version did not complained about recursive macros. The increased
limit would be nice.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It's easy to cause a recursive definition by mistake, but after seeing the jdk
spec... the macros nest deeper than anything else I've seen in rpm macro usage.
It's quite possible that you're running into the artificial limit of 16 nesting
levels.
I initiated a scratch-build where the limit is
hmmm. Moving in that, and started to slowly get in same maze where I was when
deffine was used instead of global - error: Too many levels of recursion in
macro expansion. It is likely caused by recursive macro declaration.
--
You are receiving this because you are subscribed to this thread.
I consider the \\ syntax as easy to make an error and easy to oferlook when
readed. So i would prefer matching bracket rather. Thanx.
hmm, the build failed. %1 leaked in again. Looks my small steps do not work as
I hoped...
--
You are receiving this because you are subscribed to this thread.
Not really, the surrounding %{ ... } will end up in the macro body literally
which is unlikely to be what you want. It's not a general block construct in
the sense you'd find in eg C. Use the line-continuations instead, eg
```
%define sdkbindir()\
%{_jvmdir}/%{sdkdir %1}/bin\
The:
%define sdkbindir() %{
%{_jvmdir}/%{sdkdir %1}/bin
%{_jvmdir}/%{sdkdir %1}/bin
}
Is correct right?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I'd recommend trying to eliminate those leftover %expand's and double %%-s
> necessiated by %global use, those only make reading
Thats plan to do. But in small steps. It may be easy to cause some really hard
to find issues.
> and understanding the whole thing more difficult.
Thats long
Yes, things actually become more natural when empty arguments are handled as
such. But even positive change can be a major PITA if it comes at the wrong
time, know the feeling...
I'd recommend trying to eliminate those leftover %expand's and double %%-s
necessiated by %global use, those only
Thank you. They can be nil, so ? approach is clear way.
Now building withmost direct:
https://src.fedoraproject.org/rpms/java-9-openjdk/c/abdb6134df8fd6e458e41d9a020274dd441ed2e7?branch=f27
lets see again.
The approach, once tuned here, will need to be backport to jdk8
--
You are receiving
```
%define mymacro() \
echo foo\
echo bar
```
...is the line-continuation syntax.
As for the rest, it depends on what you need to do with it. If the arguments
are always non-%{nil} then there's nothing you need to do. If arguments can be
%{nil} (or otherwise empty), then you have two choices:
On Fri, Aug 18, 2017 at 08:22:23AM +0300, Panu Matilainen wrote:
> On 08/17/2017 11:28 PM, Dmitry V. Levin wrote:
> > On Thu, Aug 17, 2017 at 08:16:12AM +0300, Panu Matilainen wrote:
> >> On 08/16/2017 11:51 PM, Dmitry V. Levin wrote:
> >>> On Thu, Aug 10, 2017 at 08:15:02PM +0300, Panu Matilainen
Sorry, to clarify again:
%global sdkbindir() %{expand:
%{_jvmdir}/%{sdkdir %%1}/bin
%{_jvmdir}/%{sdkdir %%1}/bin
}
==
%define sdkbindir() %{expand:
%{_jvmdir}/%{sdkdir %%1}/bin
%{_jvmdir}/%{sdkdir %%1}/bin
}
==
%define sdkbindir()\
%{_jvmdir}/%{sdkdir %1}/bin \
%{_jvmdir}/%{sdkdir
No, you just need to use trailing ```\``` to indicate line-continuation which
is not necessary inside %{...} "block scope".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I see. I guess when macro is multiline, I still need to use %{expand
}
oook?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The crucial difference is right there in the part you quoted:
```
%global does not work correctly with parametric macros in any version of rpm,
since the body is expanded at the time of definition instead of time of use as
is the case with %defines.
```
So basically you *can* use %global
O, and thank you very much for helping me out!
--
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/127#issuecomment-323321338___
"%global does not work correctly with parametric macros in any version of rpm,
since the body is expanded at the time of definition instead of time of use as
is the case with %defines. And the spec is full of those, combined with some
strange %{expand}s and whatnot. This is a sad example of
Thats baa... Very bad.You killed dinamic specfiles.
What I have is:
for suffix in %{build_loop} ; do
mkdir -p %{buildoutputdir $suffix}
pushd %{buildoutputdir $suffix}
done
You see that expansion as is odnenow killed it.
--
You are receiving this because you are subscribed to this
So... start by changing the %global's of parametric macros to %define().
Many/most of the accompanying %{expand:}s are likely unnecessary and unwanted
too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
%{?1} is the same as %{?1:%1}, yes. And sure it works, eg:
```
[pmatilai@sopuli ~]$ rpm --define "foo() %{?1}" --eval "%foo %{nil}"
[pmatilai@sopuli ~]$ rpm --define "foo() %{?1}" --eval "%foo %{_lib}"
lib64
```
However looking at
28 matches
Mail list logo
