Hi,
Ricardo Wurmus skribis:
> Ludovic Courtès 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
Hi Ludovic,
Ludovic Courtès writes:
> Hi,
>
> zimoun skribis:
>
>> On Wed, 24 Nov 2021 at 13:10, Ricardo Wurmus 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
Ludovic Courtès writes:
Hi,
zimoun skribis:
On Wed, 24 Nov 2021 at 13:10, Ricardo Wurmus
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
Hi,
zimoun skribis:
> On Wed, 24 Nov 2021 at 13:10, Ricardo Wurmus 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.
Hi Ricardo,
On Wed, 24 Nov 2021 at 13:10, Ricardo Wurmus 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
Hi Guix,
currently we patch source code and build systems to ensure that no
special instructions are used that would not be portable,
e.g. AVX2, SSE4.1 etc. What do you think of adding a build system
option that would allow users to restore these optimizations?
The build phases that patch
