From: ludo@gnu.org (Ludovic Courtès)
To: Alex Vong <alexvong1995@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: Add Mlucas.
Date: Tue, 06 Oct 2015 21:31:25 +0200 [thread overview]
Message-ID: <87mvvvdcaa.fsf@gnu.org> (raw)
In-Reply-To: <CADrxHD-GNm5VdOqY+xScxzO0K2shCE9rdUN1j3Fw=DqrHibbCQ@mail.gmail.com> (Alex Vong's message of "Tue, 6 Oct 2015 21:58:45 +0800")
Hi!
Alex Vong <alexvong1995@gmail.com> skribis:
> On 06/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
[...]
>> 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.
Yeah, makes sense. A phase that guesses the command to run may still
save a few lines here and there, but I agree that it may not be that
beneficial overall.
Thanks,
Ludo’.
next prev parent reply other threads:[~2015-10-06 19:31 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
2015-10-06 19:31 ` Ludovic Courtès [this message]
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=87mvvvdcaa.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=alexvong1995@gmail.com \
--cc=guix-devel@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.