Hi, Ricardo Wurmus <rek...@elephly.net> skribis:
> Ludovic Courtès <ludovic.cour...@inria.fr> writes: [...] > 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! I forgot to mention it here, but it’s available for testing and probably even ready to merge: https://issues.guix.gnu.org/52283 I think it makes an option to dismiss ‘-march’ removal unnecessary; or, put differently, it achieves the same. I’m interested in seeing which packages people would mark as “tunable” and what performance gains it gives! Thanks, Ludo’.
