Ludovic Courtès <ludovic.cour...@inria.fr> writes:
Hi,
zimoun <zimon.touto...@gmail.com> skribis:
On Wed, 24 Nov 2021 at 13:10, Ricardo Wurmus
<rek...@elephly.net> wrote:
The build phases that patch out these features would have to
check
for that build system option, much like they check the TESTS?
option before attempting to run tests.
Then it could be a transformation. The idea sounds good to
me.
I’ve been working on it last week with my HPC hat on.
To be clear, I think in may cases, passing ‘-march’ like you
suggest is
the wrong approach; instead software should use (and usually
does use)
function multi-versioning:
https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/
It may very well be the wrong approach in principle, but I also
think that it’s a neat escape hatch for specific use cases.
Separating reproducibility patching makes the package
transformation mechanism more powerful and appealing. Much like
respecting TESTS? makes it easy for users of modified packages to
bypass a failing test suite, making patching of Makefiles to
remove CPU tuning conditional would make for much less complex
custom package definitions.
I found one case though where this is not possible: C++
header-only
libraries such as Eigen contain hand-optimized vectorized
routines,
selected at build time, but we end up compiling Eigen users as
the
x86_64/AArch64 baseline, which is a waste. (If you do know of
other
problematic cases, I’m interested in taking a look!)
My solution to that is “package multi-versioning” via a
transformation
option. Hopefully I’ll submit preliminary patches within a week
or so!
Oh, exciting!
--
Ricardo
