all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alex Vong <alexvong1995@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: Add Mlucas.
Date: Tue, 6 Oct 2015 21:58:45 +0800	[thread overview]
Message-ID: <CADrxHD-GNm5VdOqY+xScxzO0K2shCE9rdUN1j3Fw=DqrHibbCQ@mail.gmail.com> (raw)
In-Reply-To: <87bnccpb3i.fsf@gnu.org>

Hi Ludovic,

On 06/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> On 05/10/2015, Mathieu Lirzin <mthl@openmailbox.org> wrote:
>>> Alex Vong <alexvong1995@gmail.com> writes:
>
> [...]
>
>>> I'm not competent enough to judge if it's a useful build-system to add
>>> but
>>> this should be done in another commit and in
>>> “guix/guix/build/bootstap-build-system.scm” if yes.
>>>
>> I should be more a newbie than you do. I just wonder if it is possible
>> to modify the build system by a little, such as adding a bootstrap
>> phase and some new inputs, and then give a name to the new build
>> system. Since it seems many packages are repeating this step, I think
>> it will be great if we have this mean of abstraction.
>
> It’s not uncommon, indeed.  However, the details on how to bootstrap are
> not standard: Often ‘autoreconf -vfi’ will do, sometimes it’s
> ‘./bootstrap’, sometimes ‘./autogen.sh’, etc.
>
> Now the proposed build system could maybe try these variants one after
> the other.
>
> Also, the set of dependencies varies: sometimes it’s Autoconf, sometimes
> Autoconf+Automake, sometimes Autoconf+Automake+Libtool, etc.  So I think
> the set of dependencies should be kept explicit–i.e., packages have to
> add stuff to ‘native-inputs’.
>
> Could you try to make this build system as a standalone commit, leaving
> out the build flags code for a separate discussion?
>
> The commit would add (guix build-system gnu-bootstrap) for instance (I
> call it this way because it bootstraps specifically the GNU build
> system, not CMake, etc.) and (guix build gnu-bootstrap-build-system).
> The latter would simply add one phase to ‘%standard-phases’.
>
> Does that make sense?
>
I think if the set of dependencies should be kept explicit, then it
seems the only thing we are left to abstract away is trying the
commands ``autoreconf -vfi'', ``./bootstrap'' and ``./autogen.sh''.
But I think the command is better left for the package maintainer to
decide since the bootstrap script may have unusual name. (I have seen
``bootstrap.sh'' for instance.) My original though is to let the
package maintainer to pass in the bootstrap command string. However,
if it is the case, then gnu-bootstrap build-system isn't abstracting
anything at all. So I think I'll go back to the original solution of
adding a new phase and specifying autotools dependencies instead.

>>>> +
>>>> +(define-public mlucas
>>>> +  ;; descriptions of the package
>>>> +  (let ((short-description
>>>> +         "Program to perform Lucas-Lehmer test on a Mersenne number")
>>>> +        (long-description
>>>> +         "mlucas is an open-source (and free/libre) program
>>>                           ^^^
>>>
>>> Being a GNU project, we use the term “free software”, but in the context
>>> of
>>> a
>>> description it is not relevant to describe freedom of a package since
>>> every
>>> package in Guix is free software.
>>>
>> "open-source" is actually mentioned in the upstream description, so I
>> add the description inside the parenthesis. But I can remove both if
>> it is desired.
>
> Yes please.  Everything is free in Guix anyway.  :-)
>
> Also, as Alex mentions, the synopsis and description must be literal
> strings in the ‘description’ and ‘synopsis’ fields.  This allows those
> strings to be extracted for translation (see “Synopses and Descriptions”
> in the manual.)
>
Yes I will fix those.

> Thank you, and welcome!
>
> Ludo’.
>
Thanks too!

Cheers,
Alex

  reply	other threads:[~2015-10-06 13:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-05  5:01 [PATCH] gnu: Add Mlucas Alex Vong
2015-10-05 10:46 ` Mathieu Lirzin
2015-10-06  3:13   ` Alex Vong
2015-10-06 10:04     ` Ludovic Courtès
2015-10-06 13:58       ` Alex Vong [this message]
2015-10-06 19:31         ` Ludovic Courtès
2015-10-06 15:06     ` Mathieu Lirzin
2015-10-06 15:31       ` Alex Kost
2015-10-05 16:42 ` Alex Kost
2015-10-06 13:43   ` Alex Vong
2015-10-06 14:40     ` Alex Kost
2015-10-06 19:28       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADrxHD-GNm5VdOqY+xScxzO0K2shCE9rdUN1j3Fw=DqrHibbCQ@mail.gmail.com' \
    --to=alexvong1995@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.