guix-devel
[Top][All Lists]
Advanced

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

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.


From: Kei Kebreau
Subject: Re: 01/01: gnu: wxmaxima: Update to 17.05.0.
Date: Sun, 30 Jul 2017 21:14:36 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> Kei Kebreau <address@hidden> writes:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> address@hidden (Kei Kebreau) writes:
>>>
>>>> @@ -2172,6 +2176,10 @@ point numbers.")
>>>>         ("shared-mime-info" ,shared-mime-info)))
>>>>      (arguments
>>>>       `(#:phases (modify-phases %standard-phases
>>>> +                  (add-before
>>>> +                   'configure 'autoconf
>>>> +                   (lambda _
>>>> +                     (zero? (system* "./bootstrap"))))
>>>
>>> In general, autoconf-style phases like this should be put after the
>>> 'unpack' phase, not before the 'configure' phase.  The reason is that on
>>> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
>>> needs to be able to operate on the generated configure script.
>>>
>>> When you move the phase earlier, you may then find that you need to
>>> launch the 'bootstrap' script differently, because its shebang will not
>>> be correct.  That's because it will now be run before the
>>> 'patch-source-shebangs' phase.
>>>
>>> So, the way we normally do this is to run something like:
>>>
>>>   (zero? (system* "sh" "bootstrap"))
>>>
>>> Grepping for "add-before 'configure" reveals that there are now a rather
>>> large number of instances of this problem.  Oh well.
>>>
>>>        Mark
>>
>> I see. Thank you for the correction.
>>
>> Do you consider it worth going through the package code and patching
>> this problem specifically or should it be corrected gradually while
>> making other changes?
>
> If you (or anyone else) is willing to work on this, I think it would be
> quite helpful to go through and fix some or all of these problems
> proactively.  It's quite common for people to look at existing packages
> for examples of how things should be done, so the presence of these
> mistakes in our tree will spawn new instances of the same mistake until
> they are eradicated :)
>
> Two things to keep in mind:
>
> * If changing a package would trigger a large number of rebuilds, the
>   change should be made on 'core-updates' instead.
>
> * For each change on 'master', we should make sure the package still
>   builds successfully before pushing it.  That should be enough testing
>   for kind of change.
>
>      Thanks!
>        Mark

I'm leaving this message here to let everyone on the list know that this
patch is being worked on. :-)

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]