Re: [PATCH 1/2] Add (guix build build-flags).

[Ludovic Courtès]

Alex Vong <address@hidden> skribis:

> From 6ad35e245c374ff828f167bb3467ce68559ccefd Mon Sep 17 00:00:00 2001
> From: Alex Vong <address@hidden>
> Date: Sat, 31 Oct 2015 19:44:13 +0800
> Subject: [PATCH 1/2] Add (guix build build-flags).
>
> A module to manipulate build flags, similar to dpkg-buildflags.
>
> * guix/build/build-flags.scm: New file.
> * Makefile.am (MODULES): Register it.

[...]

> +;;; Module to manipulate build flags, similar to dpkg-buildflags.

It doesn’t really help to refer to dpkg-buildflags, at least for me.  ;-)

> +;;; Data structure <flag-list> is constructed by flag-list.
> +;;; The constructor flag-list does something to its arguments,
> +;;; such as trimming white-spaces, to ensure no two arguments mean the same.
> +;;;
> +;;; Here is an example:
> +;;; (define default-flag-list
> +;;;   (flag-list
> +;;;    #:CFLAGS '("-O2" "-g")
> +;;;    #:LDFLAGS '("-lm" "-lpthread")))
> +;;;
> +;;; flag-list+ and flag-list- are analogous to
> +;;; numeric + and - but operate on <flag-list>.
> +;;;
> +;;; flag-list->string-list converts <flag-list> into
> +;;; configure-flags-compatible string-list.

How would we use flag lists?

The problem is that each build system has its own way to specify custom
flags, and some don’t even allow that.  So being able to manipulate flag
lists is nice, but I’m afraid we wouldn’t be able to make much out of
them.

WDYT?

> +(define-syntax define-record-type-with-accessor-list
> +  (syntax-rules ()
> +    "Macro to define a srfi-9 record
> +with accessor list bound to accessor-list-name.

Is this really needed?  Would ‘define-record-type*’ from (guix records)
do the job?

> +(define-record-type-with-accessor-list <flag-list>
> +  (make-flag-list c-flags
> +                  cpp-flags
> +                  c++-flags
> +                  fc-flags
> +                  f-flags
> +                  gcj-flags
> +                  ld-flags
> +                  objc-flags
> +                  objc++-flags)

I’m not convinced we need to list all these flags, but again, that
depends on how we end up using it.

On one hand that’s already too many flags, and we’d be passing the same
options to all of them anyway–like -fstack-protector, -fPIE, etc.

On the other hand, it’s very much GCC- and autotool-centric.

[...]

> +(define fortify-flag-list
> +  (flag-list
> +   #:CPPFLAGS '("-D_FORTIFY_SOURCE=2")))
> +
> +(define stackprotector-flag-list
> +  (flag-list
> +   #:CFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> +   #:CXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> +   #:FCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> +   #:FFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> +   #:GCJFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> +   #:OBJCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> +   #:OBJCXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")))
> +
> +(define stackprotectorstrong-flag-list
> +  (flag-list
> +   #:CFLAGS '("-fstack-protector-strong")
> +   #:CXXFLAGS '("-fstack-protector-strong")
> +   #:FCFLAGS '("-fstack-protector-strong")
> +   #:FFLAGS '("-fstack-protector-strong")
> +   #:GCJFLAGS '("-fstack-protector-strong")
> +   #:OBJCFLAGS '("-fstack-protector-strong")
> +   #:OBJCXXFLAGS '("-fstack-protector-strong")))

I’ve been thinking we should experiment with these various options.  The
way I’d do it now would be by running:

  ./configure x y z CPPFLAGS=-D_FORTIFY_SOURCE=2 CFLAGS=-fstack-protector

This would be just automatically added to #:configure-flags in
gnu-build-system.scm.

Of course, some packages would ignore them and others would break, but
that’s part of the game.  It largely have to be approached on a
case-by-case basis.

Thoughts?

Ludo’.