From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Vong Subject: Re: [PATCH] gnu: Add Mlucas. Date: Tue, 6 Oct 2015 11:13:45 +0800 Message-ID: References: <20151005130123.2091f6e4@debian> <878u7hmw2w.fsf@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjIhH-0008FM-8N for guix-devel@gnu.org; Mon, 05 Oct 2015 23:13:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjIhG-0000oV-0u for guix-devel@gnu.org; Mon, 05 Oct 2015 23:13:47 -0400 Received: from mail-ig0-x232.google.com ([2607:f8b0:4001:c05::232]:34484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjIhF-0000nl-Qp for guix-devel@gnu.org; Mon, 05 Oct 2015 23:13:45 -0400 Received: by igcpb10 with SMTP id pb10so77898350igc.1 for ; Mon, 05 Oct 2015 20:13:45 -0700 (PDT) In-Reply-To: <878u7hmw2w.fsf@openmailbox.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mathieu Lirzin Cc: guix-devel@gnu.org Hi Mathieu, On 05/10/2015, Mathieu Lirzin wrote: > Alex Vong writes: > >> From e5155b52f636bfee849268b19b81f5b6608540fd Mon Sep 17 00:00:00 2001 >> From: Alex Vong >> Date: Mon, 5 Oct 2015 12:49:49 +0800 >> Subject: [PATCH] gnu: Add Mlucas. >> >> * gnu/packages/mlucas.scm: New file. >> * gnu-system.am (GNU_SYSTEM_MODULES): Register it. >> --- > > This is quite an unusual patch. :) > >> gnu-system.am | 1 + >> gnu/packages/mlucas.scm | 283 >> ++++++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 284 insertions(+) >> create mode 100644 gnu/packages/mlucas.scm >> > [...] >> +(define-module (gnu packages mlucas) >> + #:use-module (srfi srfi-1) >> + #:use-module (guix packages) >> + #:use-module (guix download) >> + #:use-module (guix build-system gnu) >> + #:use-module (guix licenses) >> + #:use-module (gnu packages autogen) >> + #:use-module (gnu packages autotools) >> + #:use-module (gnu packages perl)) >> + >> + >> +;;; Procedures to manupulate build flags, similar to dpkg-buildflags. >> +;;; >> +;;; The data strcture flag-list is constrcuted by (flag-list >> ...) > ^^ > =E2=80=9Cconstructed=E2=80=9D How do you manage to detect this? I have run codespell on the file but it doesn't report anything! > >> +;;; The constructor flag-list does something to the argument, >> +;;; such as trimming whitespaces, to ensure no two arguments mean the >> same. >> +;;; >> +;;; The data structure flag-sublist is in fact an ordinary list >> +;;; with the following structure ( ...) >> +;;; >> +;;; Here is an example: >> +;;; (flag-list >> +;;; '(CFLAGS "-O2" "-g") >> +;;; '(LDFLAGS "-lm" "-lpthread")) >> +;;; >> +;;; flag-list+ and flag-list- are analogous to >> +;;; numberic + and - but operate on flag-list. >> +;;; >> +;;; flag-list->string-list converts flag-list into >> +;;; configure-flags-compatible string-list. >> +;;; > > IIUC these procedures are not meant to be specific the definition of > package > mlucas. So this should be in some other commit and maybe located in othe= r > file in =E2=80=9Cguix/guix/build/...=E2=80=9D directory. > > Can you explain the problem you faced with the current Guix methods to > achieve > that, and what are the benefits of =E2=80=98flag-list=E2=80=99 comparing = to them? > Flag-list is something similar to dpkg-buildflags(1), it has several sets of flags which are useful to almost all programs. For example, fortify flags will attempt to replace insecure unlimited length buffer function calls with length-limited ones. stackprotectorstrong will protect your program from stack smashing. In Debian, there is also a set of default build flags for packaging. I think it is a good idea, since not all upstream know these source hardening related flags, we should be using those by default but with an option to turn off individual sets of flags. This is like a layer above configure flags and make flags. > Example: > --8<---------------cut here---------------start------------->8--- > (arguments > '(#:configure-flags ... > #:make-flags ... > --8<---------------cut here---------------end--------------->8--- > > [...] >> +;;; implement the bootstrap-build-system using syntax-case macro >> +;;; bootstrap-build-system use a bootstrap script >> +;;; to run autoreconf and generate documentation. >> +(define-syntax package* >> + (lambda(x) >> + ;; add autoconf, automake and perl as build dependencies >> + ;; Modify the gnu-build-system >> + ;; by adding bootstrap phase before configure phase. >> + (define (extend-fields s-exp) > > I'm not competent enough to judge if it's a useful build-system to add bu= t > this should be done in another commit and in > =E2=80=9Cguix/guix/build/bootstap-build-system.scm=E2=80=9D 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. By the way, I know the macro looks ugly since this is my first time writing a macro. >> + >> +(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 =E2=80=9Cfree software=E2=80=9D, but= in the context of > a > description it is not relevant to describe freedom of a package since eve= ry > 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. > I think there will be more details to cover for an extensive review, but > let's > discuss the big lines first. > > Thanks for your contribution! > Thanks! > -- > Mathieu Lirzin > > Cheers, Alex