Re: Memoizing macro values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 02. 01. 23 10:13, Panu Matilainen wrote:
On 12/21/22 12:17, Florian Weimer wrote:
In Fedora, we have this:

/usr/lib/rpm/macros.d/macros.python:%python_sitelib %(RPM_BUILD_ROOT= %{__python} -Esc "import sysconfig; print(sysconfig.get_path('purelib', vars={'platbase': '%{_prefix}', 'base': '%{_prefix}'}))") /usr/lib/rpm/macros.d/macros.python3:%python3_sitelib %(RPM_BUILD_ROOT= %{__python3} -Ic "import sysconfig; print(sysconfig.get_path('purelib', vars={'platbase': '%{_prefix}', 'base': '%{_prefix}'}))")

This is a %define-style macro, so the macro gets re-evaluated for every
expansion.  It can make spec file operations really, really slow.

It's possible to work around this in spec files like this:

%{?python3_sitearch: %global python3_sitearch %{python3_sitearch}}

But this is quite ugly, and I wonder if there is a nice way to do it
directly in the macros file instead.  I think I know how do it with Lua,
but maybe there is a better way?

%python3_sitearch %{global python3_sitearch %(RPM_BUILD_ROOT= %{__python3} -Esc "import sysconfig; print(sysconfig.get_path('platlib', vars={'platbase': '%{_prefix}', 'base': '%{_prefix}'}))")}%{python3_sitearch}

Ie just push the evaluated macro on top of the original one as a global on first use, re-evaluation can be forced with %undefine and no helper macros needed.

How does this work when Python is installed mid-build somehow? Do we need to care about that or can we absolutely assume that when packages are installed, the RPM build process is restarted?

There's also an upstream RFE on this use-case, it's quite common indeed:

Thanks for the link.

Miro Hrončok
Phone: +420777974800
IRC: mhroncok

Rpm-list mailing list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux