[bug#67921] [PATCH v3 01/24] gnu: ghc: More robust build with binutils ≥ 2.39.

[Divya Ranjan via Guix-patches via <guix-patches@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]

> The upside is more consistent and easier to understand code in Guix, the downside is rebuild times. Only depends on how you weigh each other.

Any estimation for the ballpark within which which it might fall? Here do you mean rebuild times of each version? Like, this build time isn't going to affect user installation and creation of drvs, or would it?

On 14 November 2024 22:55:17 GMT, Nicolas Graves <ngraves@ngraves.fr> wrote:
>On 2024-11-14 17:42, Divya Ranjan wrote:
>
>> Nicolas Graves <ngraves@ngraves.fr> writes:
>>
>>> On 2024-11-13 04:47, Divya Ranjan via Guix-patches via wrote:
>>>
>>>> Hello Nicholas, Lars and others.
>>>>
>>>> I’ve planned to pick up the work needed for this upgrade. Where are we
>>>> and what more work is needed? A brief summary with specific tasks
>>>> would help me get started.
>>>
>>> I haven't managed to get much more done.  What happened is that
>>> core-updates broke the original patch series, the patch I added fixes
>>> the build of version 9.4.8 and makes a previous patch unnecessary, but
>>> the way I wrote it required to build from versions 8.6 (basically one
>>> entire day of pure build on my machine).
>>>
>>> If I were to rebuild everything from 8.6 once again, I would actually
>>> rather try the #:make-flag EXTRA_HC_OPTS (IIRC) which is definitely the
>>> same thing in 9.4.8, but it wasn't that clear in 8.6.
>>
>> Is building everything from 8.6 a good idea though? Is it /that/
>> broken?
>
>The upside is more consistent and easier to understand code in Guix, the
>downside is rebuild times.  Only depends on how you weight each other.
>
>>> From there you'll see that some tests for 9.6 are still broken.  I last
>>> was working on decoupling the build (which works) from the tests (some
>>> still failed, hard to understand why), because the rebuild is huge and
>>> makes iterations quite painful.  But even that is hard since you would
>>> need the hadrian test phase to be run to get the necessary files
>>> (hadrian config for tests and some binaries) to run tests independently
>>> in another guix package.  IIRC I stopped there but still have some
>>> progress in my stash. 
>>
>> Okay, is there any particular reason why this is being so hard? I
>> haven’t seen such problems with Nix.
>
>It is hard to get what's wrong based on the error messages.  Also when I
>tried to add options for more logging (don't remember which one I
>tested) on Hadrian's options passed to the linker (through
>EXTRA_HC_OPTS for instance), it fails because the option was
>incompatible with another one set by Hadrian.  I wanted to try more
>logging options to at least have a better understanding of what was
>going wrong, but then started on decoupling build and tests because of
>the high rebuild time.
>
>There's still ultimately the option to skip the tests, which is not
>difficult, but neither desirable. 
>>
>> Regards,
>
>-- 
>Best regards,
>Nicolas Graves

Divya Ranjan, Mathematics, Philosophy and Libre Software

[-- Attachment #2: Type: text/html, Size: 4360 bytes --]