[PATCH 1/3] gnu: libxft: Propagate input.

[PATCH 1/3] gnu: libxft: Propagate input.

[John Darrington]

* gnu/packages/xorg.scm (libxft): Propagate input libxrender.
---
 gnu/packages/xorg.scm |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm
index dfdd82c..c21ed63 100644
--- a/gnu/packages/xorg.scm
+++ b/gnu/packages/xorg.scm
@@ -1257,10 +1257,11 @@ tracking.")
           (base32
             "1gdv6559cdz1lfw73x7wsvax1fkvphmayrymprljhyyb5nwk5kkz"))))
     (build-system gnu-build-system)
+    (propagated-inputs
+      `(("libxrender" ,libxrender)))
     (inputs
       `(("libx11" ,libx11)
         ("xproto" ,xproto)
-        ("libxrender" ,libxrender)
         ("freetype" ,freetype)
         ("fontconfig" ,fontconfig)))
     (native-inputs
-- 
1.7.10.4

[PATCH 2/3] gnu: fltk: New module

[John Darrington]

* gnu/packages/fltk.scm: New file
* gnu-system.am: New file fltk.scm
---
 gnu-system.am         |    1 +
 gnu/packages/fltk.scm |   63 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)
 create mode 100644 gnu/packages/fltk.scm

diff --git a/gnu-system.am b/gnu-system.am
index 47995b5..5c01e8e 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -62,6 +62,7 @@ GNU_SYSTEM_MODULES =				\
   gnu/packages/fdisk.scm			\
   gnu/packages/file.scm				\
   gnu/packages/flex.scm				\
+  gnu/packages/fltk.scm				\
   gnu/packages/fonts.scm			\
   gnu/packages/fontutils.scm			\
   gnu/packages/freeipmi.scm			\
diff --git a/gnu/packages/fltk.scm b/gnu/packages/fltk.scm
new file mode 100644
index 0000000..245cd93
--- /dev/null
+++ b/gnu/packages/fltk.scm
@@ -0,0 +1,63 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2014 John Darrington <jmd@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages fltk)
+  #:use-module (guix licenses)
+  #:use-module (gnu packages xorg)
+  #:use-module (gnu packages gl)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu))
+
+(define-public fltk
+  (package
+    (name "fltk")
+    (version "1.3.2")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "http://fltk.org/pub/fltk/1.3.2/fltk-" version "-source.tar.gz"))
+      (sha256
+       (base32
+        "1974brlk723095vf8z72kazq1cbqr9a51kq6b0xda6zkjkgl8q0p"))))
+   (build-system gnu-build-system)
+    (inputs
+      `(("libx11" ,libx11)
+        ("mesa" ,mesa)))
+    (arguments
+     `(#:phases
+       (alist-replace
+        'check
+        (lambda* (#:key inputs #:allow-other-keys) #t) ;; fltk does not have a
+                                                      ;; check target
+        (alist-replace
+         'configure
+         (lambda* (#:key outputs #:allow-other-keys #:rest args)
+           (let ((configure (assoc-ref %standard-phases 'configure)))
+             (substitute* "makeinclude.in"
+               (("/bin/sh") (which "sh")))
+             (apply configure args)))
+         %standard-phases))))
+    (home-page "https://www.fltk.org")
+    (synopsis "3D C++ GUI library")
+    (description "FLTK is a C++ GUI toolkit providing modern GUI functionality without the
+bloat. It supports 3D graphics via OpenGL and its built-in GLUT emulation.
+FLTK is designed to be small and modular enough to be statically linked, but
+works fine as a shared library. FLTK also includes an excellent UI builder
+called FLUID that can be used to create applications in minutes.")
+    (license lgpl2.0))) ; plus certain additional permissions
-- 
1.7.10.4

Re: [PATCH 2/3] gnu: fltk: New module

[Thompson, David]

Hi John,

Noticed one small thing.

On Thu, Jan 23, 2014 at 3:07 PM, John Darrington <jmd@gnu.org> wrote:
> * gnu/packages/fltk.scm: New file
> * gnu-system.am: New file fltk.scm
> ---
>  gnu-system.am         |    1 +
>  gnu/packages/fltk.scm |   63 +++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 64 insertions(+)
>  create mode 100644 gnu/packages/fltk.scm
>
> diff --git a/gnu-system.am b/gnu-system.am
> index 47995b5..5c01e8e 100644
> --- a/gnu-system.am
> +++ b/gnu-system.am
> @@ -62,6 +62,7 @@ GNU_SYSTEM_MODULES =                          \
>    gnu/packages/fdisk.scm                       \
>    gnu/packages/file.scm                                \
>    gnu/packages/flex.scm                                \
> +  gnu/packages/fltk.scm                                \
>    gnu/packages/fonts.scm                       \
>    gnu/packages/fontutils.scm                   \
>    gnu/packages/freeipmi.scm                    \
> diff --git a/gnu/packages/fltk.scm b/gnu/packages/fltk.scm
> new file mode 100644
> index 0000000..245cd93
> --- /dev/null
> +++ b/gnu/packages/fltk.scm
> @@ -0,0 +1,63 @@
> +;;; GNU Guix --- Functional package management for GNU
> +;;; Copyright © 2014 John Darrington <jmd@gnu.org>
> +;;;
> +;;; This file is part of GNU Guix.
> +;;;
> +;;; GNU Guix is free software; you can redistribute it and/or modify it
> +;;; under the terms of the GNU General Public License as published by
> +;;; the Free Software Foundation; either version 3 of the License, or (at
> +;;; your option) any later version.
> +;;;
> +;;; GNU Guix is distributed in the hope that it will be useful, but
> +;;; WITHOUT ANY WARRANTY; without even the implied warranty of
> +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +;;; GNU General Public License for more details.
> +;;;
> +;;; You should have received a copy of the GNU General Public License
> +;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
> +
> +(define-module (gnu packages fltk)
> +  #:use-module (guix licenses)
> +  #:use-module (gnu packages xorg)
> +  #:use-module (gnu packages gl)
> +  #:use-module (guix packages)
> +  #:use-module (guix download)
> +  #:use-module (guix build-system gnu))
> +
> +(define-public fltk
> +  (package
> +    (name "fltk")
> +    (version "1.3.2")
> +    (source
> +     (origin
> +      (method url-fetch)
> +      (uri (string-append "http://fltk.org/pub/fltk/1.3.2/fltk-" version "-source.tar.gz"))

Substitute "1.3.2" with 'version'.

> +      (sha256
> +       (base32
> +        "1974brlk723095vf8z72kazq1cbqr9a51kq6b0xda6zkjkgl8q0p"))))
> +   (build-system gnu-build-system)
> +    (inputs
> +      `(("libx11" ,libx11)
> +        ("mesa" ,mesa)))
> +    (arguments
> +     `(#:phases
> +       (alist-replace
> +        'check
> +        (lambda* (#:key inputs #:allow-other-keys) #t) ;; fltk does not have a
> +                                                      ;; check target
> +        (alist-replace
> +         'configure
> +         (lambda* (#:key outputs #:allow-other-keys #:rest args)
> +           (let ((configure (assoc-ref %standard-phases 'configure)))
> +             (substitute* "makeinclude.in"
> +               (("/bin/sh") (which "sh")))
> +             (apply configure args)))
> +         %standard-phases))))
> +    (home-page "https://www.fltk.org")
> +    (synopsis "3D C++ GUI library")
> +    (description "FLTK is a C++ GUI toolkit providing modern GUI functionality without the
> +bloat. It supports 3D graphics via OpenGL and its built-in GLUT emulation.
> +FLTK is designed to be small and modular enough to be statically linked, but
> +works fine as a shared library. FLTK also includes an excellent UI builder
> +called FLUID that can be used to create applications in minutes.")
> +    (license lgpl2.0))) ; plus certain additional permissions
> --
> 1.7.10.4
>
>

- Dave

[PATCH 2/2] gnu: fltk: New module

[John Darrington]

* gnu/packages/fltk.scm: New file
* gnu-system.am: New file fltk.scm
---
 gnu-system.am         |    2 ++
 gnu/packages/fltk.scm |   63 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 65 insertions(+)
 create mode 100644 gnu/packages/fltk.scm

diff --git a/gnu-system.am b/gnu-system.am
index 31d664e..a2d85c8 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -57,12 +57,14 @@ GNU_SYSTEM_MODULES =				\
   gnu/packages/dictionaries.scm			\
   gnu/packages/docbook.scm			\
   gnu/packages/dwm.scm				\
+  gnu/packages/e2fsprogs.scm			\
   gnu/packages/ed.scm				\
   gnu/packages/elf.scm				\
   gnu/packages/emacs.scm			\
   gnu/packages/fdisk.scm			\
   gnu/packages/file.scm				\
   gnu/packages/flex.scm				\
+  gnu/packages/fltk.scm				\
   gnu/packages/fonts.scm			\
   gnu/packages/fontutils.scm			\
   gnu/packages/freeipmi.scm			\
diff --git a/gnu/packages/fltk.scm b/gnu/packages/fltk.scm
new file mode 100644
index 0000000..4c8fc3f
--- /dev/null
+++ b/gnu/packages/fltk.scm
@@ -0,0 +1,63 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2014 John Darrington <jmd@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages fltk)
+  #:use-module (guix licenses)
+  #:use-module (gnu packages xorg)
+  #:use-module (gnu packages gl)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu))
+
+(define-public fltk
+  (package
+    (name "fltk")
+    (version "1.3.2")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "http://fltk.org/pub/fltk/" version "/fltk-" version "-source.tar.gz"))
+      (sha256
+       (base32
+        "1974brlk723095vf8z72kazq1cbqr9a51kq6b0xda6zkjkgl8q0p"))))
+   (build-system gnu-build-system)
+    (inputs
+      `(("libx11" ,libx11)
+        ("mesa" ,mesa)))
+    (arguments
+     `(#:phases
+       (alist-replace
+        'check
+        (lambda* (#:key inputs #:allow-other-keys) #t) ;; fltk does not have a
+                                                       ;; check target
+        (alist-replace
+         'configure
+         (lambda* (#:key outputs #:allow-other-keys #:rest args)
+           (let ((configure (assoc-ref %standard-phases 'configure)))
+             (substitute* "makeinclude.in"
+               (("/bin/sh") (which "sh")))
+             (apply configure args)))
+         %standard-phases))))
+    (home-page "https://www.fltk.org")
+    (synopsis "3D C++ GUI library")
+    (description "FLTK is a C++ GUI toolkit providing modern GUI functionality without the
+bloat. It supports 3D graphics via OpenGL and its built-in GLUT emulation.
+FLTK is designed to be small and modular enough to be statically linked, but
+works fine as a shared library. FLTK also includes an excellent UI builder
+called FLUID that can be used to create applications in minutes.")
+    (license lgpl2.0))) ; plus certain additional permissions
-- 
1.7.10.4

(unknown),

[John Darrington]

Sorry!  Corrected patch herewith.

[PATCH] gnu: fltk: New module

[John Darrington]

* gnu/packages/fltk.scm: New file
* gnu-system.am: New file fltk.scm
---
 gnu-system.am         |    1 +
 gnu/packages/fltk.scm |   63 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)
 create mode 100644 gnu/packages/fltk.scm

diff --git a/gnu-system.am b/gnu-system.am
index 31d664e..22ef1c7 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -63,6 +63,7 @@ GNU_SYSTEM_MODULES =				\
   gnu/packages/fdisk.scm			\
   gnu/packages/file.scm				\
   gnu/packages/flex.scm				\
+  gnu/packages/fltk.scm				\
   gnu/packages/fonts.scm			\
   gnu/packages/fontutils.scm			\
   gnu/packages/freeipmi.scm			\
diff --git a/gnu/packages/fltk.scm b/gnu/packages/fltk.scm
new file mode 100644
index 0000000..4c8fc3f
--- /dev/null
+++ b/gnu/packages/fltk.scm
@@ -0,0 +1,63 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2014 John Darrington <jmd@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages fltk)
+  #:use-module (guix licenses)
+  #:use-module (gnu packages xorg)
+  #:use-module (gnu packages gl)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu))
+
+(define-public fltk
+  (package
+    (name "fltk")
+    (version "1.3.2")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "http://fltk.org/pub/fltk/" version "/fltk-" version "-source.tar.gz"))
+      (sha256
+       (base32
+        "1974brlk723095vf8z72kazq1cbqr9a51kq6b0xda6zkjkgl8q0p"))))
+   (build-system gnu-build-system)
+    (inputs
+      `(("libx11" ,libx11)
+        ("mesa" ,mesa)))
+    (arguments
+     `(#:phases
+       (alist-replace
+        'check
+        (lambda* (#:key inputs #:allow-other-keys) #t) ;; fltk does not have a
+                                                       ;; check target
+        (alist-replace
+         'configure
+         (lambda* (#:key outputs #:allow-other-keys #:rest args)
+           (let ((configure (assoc-ref %standard-phases 'configure)))
+             (substitute* "makeinclude.in"
+               (("/bin/sh") (which "sh")))
+             (apply configure args)))
+         %standard-phases))))
+    (home-page "https://www.fltk.org")
+    (synopsis "3D C++ GUI library")
+    (description "FLTK is a C++ GUI toolkit providing modern GUI functionality without the
+bloat. It supports 3D graphics via OpenGL and its built-in GLUT emulation.
+FLTK is designed to be small and modular enough to be statically linked, but
+works fine as a shared library. FLTK also includes an excellent UI builder
+called FLUID that can be used to create applications in minutes.")
+    (license lgpl2.0))) ; plus certain additional permissions
-- 
1.7.10.4

Re: [PATCH] gnu: fltk: New module

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> * gnu/packages/fltk.scm: New file
> * gnu-system.am: New file fltk.scm

Pushed, thanks!

Ludo’.

[PATCH 3/3] gnu: Add octave and dependencies

[John Darrington]

* gnu/packages/maths.scm (octave gnuplot): New variables
---
 gnu/packages/maths.scm |   88 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 640d502..ffa2cd9 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -25,16 +25,25 @@
   #:use-module (guix download)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build utils)
   #:use-module (gnu packages compression)
+  #:use-module (gnu packages curl)
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages gettext)
+  #:use-module (gnu packages ghostscript)
+  #:use-module (gnu packages fltk)
   #:use-module (gnu packages gcc)
+  #:use-module (gnu packages gl)
   #:use-module (gnu packages gtk)
+  #:use-module (gnu packages less)
   #:use-module (gnu packages multiprecision)
+  #:use-module (gnu packages pcre)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages python)
   #:use-module (gnu packages readline)
+  #:use-module (gnu packages texinfo)
+  #:use-module (gnu packages xorg)
   #:use-module (gnu packages xml))
 
 (define-public units
@@ -202,3 +211,82 @@ output in text, PostScript, PDF or HTML.")
 problems in numerical linear algebra.")
     (license (license:bsd-style "file://LICENSE"
                                 "See LICENSE in the distribution."))))
+
+(define-public gnuplot
+  (package
+    (name "gnuplot")
+    (version "4.6.3")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "mirror://sourceforge/gnuplot/gnuplot/"
+                                version "/gnuplot-" version ".tar.gz"))
+      (sha256
+       (base32
+        "1xd7gqdhlk7k1p9yyqf9vkk811nadc7m4si0q3nb6cpv4pxglpyz"))
+      ))
+    (build-system gnu-build-system)
+    (home-page "http://www.gnuplot.info")
+    (synopsis "command-line driven graphing utility.")
+    (description "Gnuplot  is a portable command-line driven graphing
+utility. It was originally created to allow scientists and students to
+visualize mathematical functions and data interactively, but has grown to
+support many non-interactive uses such as web scripting. It is also used as a
+plotting engine by third-party applications like Octave.") 
+    (license 
+     license:fsf-free))) ; http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright 
+                         ;  X11 Style with the additional restriction that
+                         ;  derived works may only be distributed as patches
+                         ;  to the original.
+
+
+(define-public octave
+  (package
+    (name "octave")
+    (version "3.8.0")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "mirror://gnu/octave/octave-"
+                          version ".tar.gz"))
+      (sha256
+       (base32
+        "0ks9pr154syw0vb3jn6xsnrkkrbvf9y7i7gaxa28rz6ngxbxvq9l"))))
+    (build-system gnu-build-system)
+    (inputs
+     `(("lapack" ,lapack)
+       ("readline" ,readline)
+       ("glpk" ,glpk)
+       ("curl" ,curl)
+       ("pcre" ,pcre)
+       ("fltk" ,fltk)
+       ("fontconfig" ,fontconfig)
+       ("freetype" ,freetype)
+       ("libxft" ,libxft)
+       ("mesa" ,mesa)
+       ("zlib" ,zlib)))
+    (native-inputs
+     `(("gfortran" ,gfortran-4.8)
+       ("perl" ,perl)
+       ("less" ,less)
+       ("pkg-config" ,pkg-config)
+       ("texinfo" ,texinfo)
+       ("ghostscript" ,ghostscript)
+       ("gnuplot" ,gnuplot)))
+    (propagated-inputs
+      `(("texinfo" ,texinfo)
+        ("less" ,less)
+        ("ghostscript" ,ghostscript)
+        ("gnuplot" ,gnuplot)))
+    (arguments
+     `(#:configure-flags (list (string-append "--with-shell=" 
+                            (assoc-ref %build-inputs "bash")
+                            "/bin/sh"))))
+    (home-page "http://www.gnu.org/software/octave/")
+    (synopsis "High-level language for numerical computation")
+    (description "GNU Octave is a high-level interpreted language that is specialized
+for numerical computations.  It can be used for both linear and non-linear
+applications and it provides great support for visualizing results.  Work may
+be performed both at the interactive command-line as well as via script
+files.")
+    (license license:gpl3+)))
-- 
1.7.10.4

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> * gnu/packages/maths.scm (octave gnuplot): New variables

Should be “(octave, gnuplot)”.

> +(define-public gnuplot
> +  (package
> +    (name "gnuplot")
> +    (version "4.6.3")
> +    (source
> +     (origin
> +      (method url-fetch)
> +      (uri (string-append "mirror://sourceforge/gnuplot/gnuplot/"
> +                                version "/gnuplot-" version ".tar.gz"))
> +      (sha256
> +       (base32
> +        "1xd7gqdhlk7k1p9yyqf9vkk811nadc7m4si0q3nb6cpv4pxglpyz"))
> +      ))

Please move the closing parens to the previous line.

> +    (build-system gnu-build-system)
> +    (home-page "http://www.gnuplot.info")
> +    (synopsis "command-line driven graphing utility.")

Start with a capital letter and remove the final period.

> +    (description "Gnuplot  is a portable command-line driven graphing
                            ^^
Extra space.
                            
> +    (license 
> +     license:fsf-free))) ; http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright 
> +                         ;  X11 Style with the additional restriction that
> +                         ;  derived works may only be distributed as patches
> +                         ;  to the original.

‘fsf-free’ is actually a procedure, so it should be:

  (license (license:fsf-free "http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright"))

The comment should be kept just above.
> +    (native-inputs
> +     `(("gfortran" ,gfortran-4.8)
> +       ("perl" ,perl)
> +       ("less" ,less)
> +       ("pkg-config" ,pkg-config)
> +       ("texinfo" ,texinfo)
> +       ("ghostscript" ,ghostscript)
> +       ("gnuplot" ,gnuplot)))
> +    (propagated-inputs
> +      `(("texinfo" ,texinfo)
> +        ("less" ,less)
> +        ("ghostscript" ,ghostscript)
> +        ("gnuplot" ,gnuplot)))

Oh, seems like a case where native inputs need to be propagated.

Why do less, Texinfo, etc. need to be propagated?

If that’s because Octave expects them to be in $PATH, then maybe an
option would be to use ‘wrap-program’ to wrap the ‘octave’ program with
a shell script that initialize $PATH to contain these.

That way, we make sure Octave will run with the “right” versions of
these (those used at compile time and known to work), and the user’s
environment doesn’t end up pulling them.

An example of ‘wrap-program’ is Git (in version-control.scm.)

Other than that, looks great to me!

Thanks!

Ludo’.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

On Sat, Jan 25, 2014 at 04:30:30PM +0100, Ludovic Court??s wrote:

     > +    (native-inputs
     > +     `(("gfortran" ,gfortran-4.8)
     > +       ("perl" ,perl)
     > +       ("less" ,less)
     > +       ("pkg-config" ,pkg-config)
     > +       ("texinfo" ,texinfo)
     > +       ("ghostscript" ,ghostscript)
     > +       ("gnuplot" ,gnuplot)))
     > +    (propagated-inputs
     > +      `(("texinfo" ,texinfo)
     > +        ("less" ,less)
     > +        ("ghostscript" ,ghostscript)
     > +        ("gnuplot" ,gnuplot)))
     
     Oh, seems like a case where native inputs need to be propagated.
     
     Why do less, Texinfo, etc. need to be propagated?

The octave build system is rather naive.  These propagated inputs don't actually
*need* to be present at configure/build time.  But the ./configure (rather stupidly IMO)
checks for their presence, and turns off the relevant features if they are not found.
Therefore, one must declare them as native-inputs just to keep ./configure happy AND
as propagated inputs because they are called in a pipe from the octave program itself.
     
     If that???s because Octave expects them to be in $PATH, then maybe an
     option would be to use ???wrap-program??? to wrap the ???octave??? program with
     a shell script that initialize $PATH to contain these.
     
     That way, we make sure Octave will run with the ???right??? versions of
     these (those used at compile time and known to work), and the user???s
     environment doesn???t end up pulling them.
     
     An example of ???wrap-program??? is Git (in version-control.scm.)

I don't think this will work in this case, for reasons explained above.

J'
     
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Andreas Enge]

On Sat, Jan 25, 2014 at 05:14:57PM +0100, John Darrington wrote:
> The octave build system is rather naive.  These propagated inputs don't actually
> *need* to be present at configure/build time.  But the ./configure (rather stupidly IMO)
> checks for their presence, and turns off the relevant features if they are not found.
> Therefore, one must declare them as native-inputs just to keep ./configure happy AND
> as propagated inputs because they are called in a pipe from the octave program itself.

Would it be reasonable to patch the lines in which external programs are
called, replacing the program name by its complete path with a well-chosen
(substitute*)?
Then one would not need to propagate the inputs.

Andreas

Re: [PATCH 3/3] gnu: Add octave and dependencies

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

On Sat, Jan 25, 2014 at 05:42:17PM +0100, Andreas Enge wrote:
     On Sat, Jan 25, 2014 at 05:14:57PM +0100, John Darrington wrote:
     > The octave build system is rather naive.  These propagated inputs don't actually
     > *need* to be present at configure/build time.  But the ./configure (rather stupidly IMO)
     > checks for their presence, and turns off the relevant features if they are not found.
     > Therefore, one must declare them as native-inputs just to keep ./configure happy AND
     > as propagated inputs because they are called in a pipe from the octave program itself.
     
     Would it be reasonable to patch the lines in which external programs are
     called, replacing the program name by its complete path with a well-chosen
     (substitute*)?
     Then one would not need to propagate the inputs.
     
I don't think that will work.  One needs to propagate the inputs.  Otherwise octave won't
work (properly).  For example, one needs to ensure that when octave is installed, less is
also installed.  Otherwise it wont have a pager.  Similarly for texinfo - if makeinfo does
not get installed along with octave, then the integrated documentation won't be available.

A better approach would be to patch the configure so that it does not bother to check for
these programs AND then to patch the install phase to check for them.  But I don't fancy
doing that.

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> On Sat, Jan 25, 2014 at 05:42:17PM +0100, Andreas Enge wrote:
>      On Sat, Jan 25, 2014 at 05:14:57PM +0100, John Darrington wrote:
>      > The octave build system is rather naive.  These propagated inputs don't actually
>      > *need* to be present at configure/build time.  But the ./configure (rather stupidly IMO)
>      > checks for their presence, and turns off the relevant features if they are not found.
>      > Therefore, one must declare them as native-inputs just to keep ./configure happy AND
>      > as propagated inputs because they are called in a pipe from the octave program itself.
>      
>      Would it be reasonable to patch the lines in which external programs are
>      called, replacing the program name by its complete path with a well-chosen
>      (substitute*)?
>      Then one would not need to propagate the inputs.
>      
> I don't think that will work.

I think it would.  If there’s a line like:

  execlp ("makeinfo" ...);

patching that to, say:

  execl ("/.../bin/makeinfo" ...);

will definitely work.  (This is what Octave’s build system should be
doing, actually.)

WDYT?

(As an example, see how mingetty is patched to refer to a specific
‘login’ program, in admin.scm.)

Ludo’.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

On Sat, Jan 25, 2014 at 09:41:32PM +0100, Ludovic Court??s wrote:
     John Darrington <john@darrington.wattle.id.au> skribis:
     
     > On Sat, Jan 25, 2014 at 05:42:17PM +0100, Andreas Enge wrote:
     >      On Sat, Jan 25, 2014 at 05:14:57PM +0100, John Darrington wrote:
     >      > The octave build system is rather naive.  These propagated inputs don't actually
     >      > *need* to be present at configure/build time.  But the ./configure (rather stupidly IMO)
     >      > checks for their presence, and turns off the relevant features if they are not found.
     >      > Therefore, one must declare them as native-inputs just to keep ./configure happy AND
     >      > as propagated inputs because they are called in a pipe from the octave program itself.
     >      
     >      Would it be reasonable to patch the lines in which external programs are
     >      called, replacing the program name by its complete path with a well-chosen
     >      (substitute*)?
     >      Then one would not need to propagate the inputs.
     >      
     > I don't think that will work.
     
     I think it would.  If there???s a line like:
     
       execlp ("makeinfo" ...);
     
     patching that to, say:
     
       execl ("/.../bin/makeinfo" ...);
     
     will definitely work.  (This is what Octave???s build system should be
     doing, actually.)
     
     WDYT?
     
     (As an example, see how mingetty is patched to refer to a specific
     ???login??? program, in admin.scm.)
     
I think I see where you are coming from.  If we did what you suggest, then we could remove
makeinfo et al from propagated-inputs, but we would have to add them to inputs (in 
to native-inputs).

So it would not reduce the total number of "inputs".  Further, it would mean we would have
to devise a number of potentially complicated patches, which we would be condemned to
maintain.  Further, it seems to me, to be a bit deceptive.  By removing makeinfo from
propagated-inputs we are pretending that makeinfo does not need to be installed along with
octave, whereas in fact, it does (if one wants to read the manual from within octave).
As I understand it, a propagated input means that X must always be installed with Y.

What benefit does this proposal bring us?

J'


-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

(unknown),

[John Darrington]

... In the meantime, here is a patch for gnuplot (without octave).
This one includes some additional inputs not present in the previous
patch, to provide some features.

[PATCH] gnu: Add gnuplot

[John Darrington]

* gnu/packages/maths.scm (gnuplot): New variable
---
 gnu/packages/maths.scm |   33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 640d502..206ebba 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -29,12 +29,14 @@
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages gettext)
   #:use-module (gnu packages gcc)
+  #:use-module (gnu packages gd)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages multiprecision)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages python)
   #:use-module (gnu packages readline)
+  #:use-module (gnu packages texlive)
   #:use-module (gnu packages xml))
 
 (define-public units
@@ -202,3 +204,34 @@ output in text, PostScript, PDF or HTML.")
 problems in numerical linear algebra.")
     (license (license:bsd-style "file://LICENSE"
                                 "See LICENSE in the distribution."))))
+
+(define-public gnuplot
+  (package
+    (name "gnuplot")
+    (version "4.6.3")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "mirror://sourceforge/gnuplot/gnuplot/"
+                                version "/gnuplot-" version ".tar.gz"))
+      (sha256
+       (base32
+        "1xd7gqdhlk7k1p9yyqf9vkk811nadc7m4si0q3nb6cpv4pxglpyz"))))
+    (build-system gnu-build-system)
+    (inputs `(("readline" ,readline)
+              ("cairo" ,cairo)
+              ("pango" ,pango)
+              ("gd" ,gd)))
+    (native-inputs `(("texlive" ,texlive)
+                     ("pkg-config" ,pkg-config)))
+    (home-page "http://www.gnuplot.info")
+    (synopsis "Command-line driven graphing utility")
+    (description "Gnuplot is a portable command-line driven graphing
+utility. It was originally created to allow scientists and students to
+visualize mathematical functions and data interactively, but has grown to
+support many non-interactive uses such as web scripting. It is also used as a
+plotting engine by third-party applications like Octave.") 
+    ;;  X11 Style with the additional restriction that derived works may only be
+    ;;  distributed as patches to the original. 
+    (license (license:fsf-free
+              "http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright"))))
-- 
1.7.10.4

Re: [PATCH] gnu: Add gnuplot

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> * gnu/packages/maths.scm (gnuplot): New variable

Pushed, thanks!

Ludo’.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Andreas Enge]

On Sun, Jan 26, 2014 at 08:38:16AM +0100, John Darrington wrote:
> So it would not reduce the total number of "inputs".  Further, it would mean we would have
> to devise a number of potentially complicated patches, which we would be condemned to
> maintain.  Further, it seems to me, to be a bit deceptive.  By removing makeinfo from
> propagated-inputs we are pretending that makeinfo does not need to be installed along with
> octave, whereas in fact, it does (if one wants to read the manual from within octave).
> As I understand it, a propagated input means that X must always be installed with Y.
> 
> What benefit does this proposal bring us?

I think that from a functional point of view, it could be preferable to have
octave "deep link" to its own dependency in the nix store, but I am not sure
if I understand things correctly.

Assume that octave is compiled with an old version of makeinfo (where "old
version" could simply mean that a dependency of makeinfo has been updated
in the mean time, or some of the build tools). At the time of installing
octave, it thus pulled the propagated input makeinfo into the user profile.
Now the user installs makeinfo; normally, this should be the new one.
I think right now, there is a warning about a conflict, and then one or the
other takes precedence; I assume the newer one (is this decided on a file
by file basis?). So octave has been compiled against an old makeinfo, but
ends up using a newer one. (Something like this has happened to me with
ripperx and cdparanoia; I installed both at different times, and got the
slightly confusing message that cdparanoia collided with itself). This seems
to be a rather annoying "feature" of our propagated inputs, and if what
I wrote above is true, they should probably be avoided as much as possible.
Ludovic, can you comment?

Andreas

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Jan 26, 2014 at 08:38:16AM +0100, John Darrington wrote:
>> So it would not reduce the total number of "inputs".  Further, it would mean we would have
>> to devise a number of potentially complicated patches, which we would be condemned to
>> maintain.  Further, it seems to me, to be a bit deceptive.  By removing makeinfo from
>> propagated-inputs we are pretending that makeinfo does not need to be installed along with
>> octave, whereas in fact, it does (if one wants to read the manual from within octave).
>> As I understand it, a propagated input means that X must always be installed with Y.
>> 
>> What benefit does this proposal bring us?
>
> I think that from a functional point of view, it could be preferable to have
> octave "deep link" to its own dependency in the nix store, but I am not sure
> if I understand things correctly.
>
> Assume that octave is compiled with an old version of makeinfo (where "old
> version" could simply mean that a dependency of makeinfo has been updated
> in the mean time, or some of the build tools). At the time of installing
> octave, it thus pulled the propagated input makeinfo into the user profile.
> Now the user installs makeinfo; normally, this should be the new one.
> I think right now, there is a warning about a conflict, and then one or the
> other takes precedence; I assume the newer one (is this decided on a file
> by file basis?). So octave has been compiled against an old makeinfo, but
> ends up using a newer one. (Something like this has happened to me with
> ripperx and cdparanoia; I installed both at different times, and got the
> slightly confusing message that cdparanoia collided with itself). This seems
> to be a rather annoying "feature" of our propagated inputs, and if what
> I wrote above is true, they should probably be avoided as much as possible.
> Ludovic, can you comment?

Yes, you explained it very well.

The functional model is that anything a package depends on at compile
time, or will depend on at run time, is specified in its definition.
When running ‘make && make check’, we check that the package works
correctly with this particular set of inputs.  What we want is that,
when users install the package, it ends up using the inputs that were
specified.

With ‘propagated-inputs’ here, this would be sort-of achieved, because
when installing Octave, the corresponding Texinfo would also get
installed.

However, that is very inconvenient: what if the user also wants to
install another Texinfo version in their profile?  Either the
user-chosen version wins, and Octave may end up working incorrectly; or
Octave’s version wins, and the user doesn’t have what they asked for.

To summarize: ‘propagated-inputs’ should list libraries 99% of the
time.  Listing programs in ‘propagated-inputs’ just for the sake of
populating $PATH is a bad idea.

HTH,
Ludo’.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[John Darrington]

On Sun, Jan 26, 2014 at 08:30:02PM +0100, Ludovic Court??s wrote:
     Andreas Enge <andreas@enge.fr> skribis:
     
     > On Sun, Jan 26, 2014 at 08:38:16AM +0100, John Darrington wrote:
     >> So it would not reduce the total number of "inputs".  Further, it would mean we would have
     >> to devise a number of potentially complicated patches, which we would be condemned to
     >> maintain.  Further, it seems to me, to be a bit deceptive.  By removing makeinfo from
     >> propagated-inputs we are pretending that makeinfo does not need to be installed along with
     >> octave, whereas in fact, it does (if one wants to read the manual from within octave).
     >> As I understand it, a propagated input means that X must always be installed with Y.
     >> 
     >> What benefit does this proposal bring us?
     >
     > I think that from a functional point of view, it could be preferable to have
     > octave "deep link" to its own dependency in the nix store, but I am not sure
     > if I understand things correctly.
     >
     > Assume that octave is compiled with an old version of makeinfo (where "old
     > version" could simply mean that a dependency of makeinfo has been updated
     > in the mean time, or some of the build tools). At the time of installing
     > octave, it thus pulled the propagated input makeinfo into the user profile.
     > Now the user installs makeinfo; normally, this should be the new one.
     > I think right now, there is a warning about a conflict, and then one or the
     > other takes precedence; I assume the newer one (is this decided on a file
     > by file basis?). So octave has been compiled against an old makeinfo, but
     > ends up using a newer one. (Something like this has happened to me with
     > ripperx and cdparanoia; I installed both at different times, and got the
     > slightly confusing message that cdparanoia collided with itself). This seems
     > to be a rather annoying "feature" of our propagated inputs, and if what
     > I wrote above is true, they should probably be avoided as much as possible.
     > Ludovic, can you comment?
     
     Yes, you explained it very well.
     
     The functional model is that anything a package depends on at compile
     time, or will depend on at run time, is specified in its definition.
     When running ???make && make check???, we check that the package works
     correctly with this particular set of inputs.  What we want is that,
     when users install the package, it ends up using the inputs that were
     specified.
     
     With ???propagated-inputs??? here, this would be sort-of achieved, because
     when installing Octave, the corresponding Texinfo would also get
     installed.
     
     However, that is very inconvenient: what if the user also wants to
     install another Texinfo version in their profile?  Either the
     user-chosen version wins, and Octave may end up working incorrectly; or
     Octave???s version wins, and the user doesn???t have what they asked for.
     
     To summarize: ???propagated-inputs??? should list libraries 99% of the
     time.  Listing programs in ???propagated-inputs??? just for the sake of
     populating $PATH is a bad idea.


Ok.  Andraes' and Ludo's explanations convince me.  However I'm skeptical that
the Octave devs would be quite so convinced.  And removing the propagates-inputs
will mean patching to the Octave source and I don't know how difficult this will be.
I will do some experiments and see how far I get.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> On Sun, Jan 26, 2014 at 08:30:02PM +0100, Ludovic Court??s wrote:
>      Andreas Enge <andreas@enge.fr> skribis:
>      
>      > On Sun, Jan 26, 2014 at 08:38:16AM +0100, John Darrington wrote:
>      >> So it would not reduce the total number of "inputs".  Further, it would mean we would have
>      >> to devise a number of potentially complicated patches, which we would be condemned to
>      >> maintain.  Further, it seems to me, to be a bit deceptive.  By removing makeinfo from
>      >> propagated-inputs we are pretending that makeinfo does not need to be installed along with
>      >> octave, whereas in fact, it does (if one wants to read the manual from within octave).
>      >> As I understand it, a propagated input means that X must always be installed with Y.
>      >> 
>      >> What benefit does this proposal bring us?
>      >
>      > I think that from a functional point of view, it could be preferable to have
>      > octave "deep link" to its own dependency in the nix store, but I am not sure
>      > if I understand things correctly.
>      >
>      > Assume that octave is compiled with an old version of makeinfo (where "old
>      > version" could simply mean that a dependency of makeinfo has been updated
>      > in the mean time, or some of the build tools). At the time of installing
>      > octave, it thus pulled the propagated input makeinfo into the user profile.
>      > Now the user installs makeinfo; normally, this should be the new one.
>      > I think right now, there is a warning about a conflict, and then one or the
>      > other takes precedence; I assume the newer one (is this decided on a file
>      > by file basis?). So octave has been compiled against an old makeinfo, but
>      > ends up using a newer one. (Something like this has happened to me with
>      > ripperx and cdparanoia; I installed both at different times, and got the
>      > slightly confusing message that cdparanoia collided with itself). This seems
>      > to be a rather annoying "feature" of our propagated inputs, and if what
>      > I wrote above is true, they should probably be avoided as much as possible.
>      > Ludovic, can you comment?
>      
>      Yes, you explained it very well.
>      
>      The functional model is that anything a package depends on at compile
>      time, or will depend on at run time, is specified in its definition.
>      When running ???make && make check???, we check that the package works
>      correctly with this particular set of inputs.  What we want is that,
>      when users install the package, it ends up using the inputs that were
>      specified.
>      
>      With ???propagated-inputs??? here, this would be sort-of achieved, because
>      when installing Octave, the corresponding Texinfo would also get
>      installed.
>      
>      However, that is very inconvenient: what if the user also wants to
>      install another Texinfo version in their profile?  Either the
>      user-chosen version wins, and Octave may end up working incorrectly; or
>      Octave???s version wins, and the user doesn???t have what they asked for.
>      
>      To summarize: ???propagated-inputs??? should list libraries 99% of the
>      time.  Listing programs in ???propagated-inputs??? just for the sake of
>      populating $PATH is a bad idea.
>
>
> Ok.  Andraes' and Ludo's explanations convince me.  However I'm skeptical that
> the Octave devs would be quite so convinced.  And removing the propagates-inputs
> will mean patching to the Octave source and I don't know how difficult this will be.

The patch that would be great upstream is:

  AC_PATH_PROG([MAKEINFO], [makeinfo])
  AC_SUBST([MAKEINFO])

and then use “@MAKEINFO@” wherever ‘makeinfo’ is expected in the source
(similarly for ‘less’, etc.)

The patch that we can do in the meantime is similar to what is done for
‘glibc’ in base.scm:

  ;; Have `system' use that Bash.
  (substitute* "sysdeps/posix/system.c"
    (("#define[[:blank:]]+SHELL_PATH.*$")
     (format #f "#define SHELL_PATH \"~a/bin/bash\"\n"
             out)))

  ;; Same for `popen'.
  (substitute* "libio/iopopen.c"
    (("/bin/sh")
     (string-append out "/bin/bash")))

HTH,
Ludo’.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[John Darrington]

On Mon, Jan 27, 2014 at 10:11:14AM +0100, Ludovic Court??s wrote:

     > Ok.  Andraes' and Ludo's explanations convince me.  However I'm skeptical that
     > the Octave devs would be quite so convinced.  And removing the propagates-inputs
     > will mean patching to the Octave source and I don't know how difficult this will be.
     
     The patch that would be great upstream is:
     
       AC_PATH_PROG([MAKEINFO], [makeinfo])
       AC_SUBST([MAKEINFO])
     
     and then use ???@MAKEINFO@??? wherever ???makeinfo??? is expected in the source
     (similarly for ???less???, etc.)

     Ludo???.

Having thought about this some more, looked to see what is currently in the 
octave source and "discussed" the issue on #octave I think now the best solution
is to simply remove all the propagated-inputs from the package (and leave inputs
and native-inputs as they are).  Rationale:

* Octave "works" without all these programs (albeit in a rather featureless 
  fashion).  If a user wants to add the feature, then she just needs to 
  guix package -i <foo>.
* It seems to have been a deliberate decision by the octave developers to rely 
  on $PATH to select the appropriate version of these external programs.
* Changing this behaviour would involve alterations to the octave source touching 
  many files, and I think upstream would be unlikely to cooperate with us.

The disadvantage of this approach is, that a guix user who installs octave, but 
not the other packages, gets only a barely functional version.  Perhaps we need 
a (recommended-inputs `(...)) like in debian.


Comments?


J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> On Mon, Jan 27, 2014 at 10:11:14AM +0100, Ludovic Court??s wrote:
>
>      > Ok.  Andraes' and Ludo's explanations convince me.  However I'm skeptical that
>      > the Octave devs would be quite so convinced.  And removing the propagates-inputs
>      > will mean patching to the Octave source and I don't know how difficult this will be.
>      
>      The patch that would be great upstream is:
>      
>        AC_PATH_PROG([MAKEINFO], [makeinfo])
>        AC_SUBST([MAKEINFO])
>      
>      and then use ???@MAKEINFO@??? wherever ???makeinfo??? is expected in the source
>      (similarly for ???less???, etc.)
>
>      Ludo???.
>
> Having thought about this some more, looked to see what is currently in the 
> octave source and "discussed" the issue on #octave I think now the best solution
> is to simply remove all the propagated-inputs from the package (and leave inputs
> and native-inputs as they are).  Rationale:
>
> * Octave "works" without all these programs (albeit in a rather featureless 
>   fashion).  If a user wants to add the feature, then she just needs to 
>   guix package -i <foo>.
> * It seems to have been a deliberate decision by the octave developers to rely 
>   on $PATH to select the appropriate version of these external programs.
> * Changing this behaviour would involve alterations to the octave source touching 
>   many files, and I think upstream would be unlikely to cooperate with us.

Item #2 is definitely a good reason to leave things untouched (no
propagation, no patching.)

> The disadvantage of this approach is, that a guix user who installs octave, but 
> not the other packages, gets only a barely functional version.  Perhaps we need 
> a (recommended-inputs `(...)) like in debian.

Yes, that would make sense.

Could you file this to bug-guix@gnu.org (with the ‘wishlist’ tag, if you
master Debbugs)?

TIA,
Ludo’.

Re: [PATCH 3/3] gnu: Add octave and dependencies

[Sree Harsha Totakura]

On 01/26/2014 08:30 PM, Ludovic Courtès wrote:
> To summarize: ‘propagated-inputs’ should list libraries 99% of the
> time.  Listing programs in ‘propagated-inputs’ just for the sake of
> populating $PATH is a bad idea.

I recently found that many library packages do not propagate libc.  I
installed gnutls through Guix and wanted to use it for development, but
the linker complained that some symbols belonging to glibc are missing.
 What is the correct way of doing this?

Sree

Installing a C tool chain

[Ludovic Courtès]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> On 01/26/2014 08:30 PM, Ludovic Courtès wrote:
>> To summarize: ‘propagated-inputs’ should list libraries 99% of the
>> time.  Listing programs in ‘propagated-inputs’ just for the sake of
>> populating $PATH is a bad idea.
>
> I recently found that many library packages do not propagate libc.  I
> installed gnutls through Guix and wanted to use it for development, but
> the linker complained that some symbols belonging to glibc are missing.
>  What is the correct way of doing this?

This is undocumented/suboptimal territory.

To install a working C environment in your profile, run:

  guix package -i gcc binutils ld-wrapper glibc

and set the environment as suggested.  (‘ld-wrapper’ is a linker wrapper
that takes care of adding a ‘-rpath’ flag for every ‘-l’; see
ld-wrapper.scm.)

The crux here is that ‘ld-wrapper’ must come *after* ‘binutils’ on the
command line above, so that $profile/bin/ld points to it, and not to the
real ‘ld’.

I believe this could be addressed by having a simple “toolchain”
meta-package with the sole purpose of propagating these 4 inputs, and by
documenting it in the manual.

WDYT?

Ludo’.

Re: Installing a C tool chain

[Sree Harsha Totakura]

On 01/27/2014 10:53 AM, Ludovic Courtès wrote:
> 
> I believe this could be addressed by having a simple “toolchain”
> meta-package with the sole purpose of propagating these 4 inputs, and by
> documenting it in the manual.

Yes, a toolchain package would be nice.  Debian does similarly: it has
build-essential package.

Sree

Re: Installing a C tool chain

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> To install a working C environment in your profile, run:
>
>   guix package -i gcc binutils ld-wrapper glibc

[...]

> I believe this could be addressed by having a simple “toolchain”
> meta-package with the sole purpose of propagating these 4 inputs, and by
> documenting it in the manual.

FWIW, I think we should do this.

    Mark

Re: Installing a C tool chain

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> To install a working C environment in your profile, run:
>>
>>   guix package -i gcc binutils ld-wrapper glibc
>
> [...]
>
>> I believe this could be addressed by having a simple “toolchain”
>> meta-package with the sole purpose of propagating these 4 inputs, and by
>> documenting it in the manual.
>
> FWIW, I think we should do this.

Commit a28ef66 adds a ‘gcc-toolchain’ meta-package:

  guix package -i gcc-toolchain

effectively installs gcc, glibc, ld-wrapper, and binutils (in the right
order), and:

  guix package -i gcc-toolchain:debug

install libc’s corresponding debugging symbols.

Comments welcome!

Ludo’.

Re: Installing a C tool chain

[Andreas Enge]

On Sat, Apr 05, 2014 at 10:44:55PM +0200, Ludovic Courtès wrote:
> Comments welcome!

This could be a useful package! Do I need to set any more environment
variables in my .bashrc? So far, I have
export PATH=$HOME/.guix-profile/bin:$PATH
export LIBRARY_PATH=$HOME/.guix-profile/lib
export CPATH=$HOME/.guix-profile/include
export MANPATH=$HOME/.guix-profile/share/man:/usr/share/man
export PKG_CONFIG_PATH=$HOME/.guix-profile/lib/pkgconfig:/usr/lib/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig
export PYTHONPATH=$HOME/.guix-profile/lib/python2.7/site-packages
export PERL5LIB=$HOME/.guix-profile/lib/perl5/site_perl
export XDG_DATA_DIRS=$HOME/.guix-profile/share


When I do a "./configure" of mpc, none of the standard headers are recognised;
I obtain something like:

configure:12920: checking for ANSI C header files
configure:13024: result: yes
configure:13035: checking locale.h usability
configure:13035: gcc -std=gnu99 -c -g -Werror -g -std=c99 -pedantic -Wno-long-long -Wall -Wextra -Wdeclaration-after-statement -Wundef -Wshadow -Wmissing-prototypes -Wno-unused-value -Wlogical-op -I/usr/local/gmp-6.0.0a/include -I/usr/local/mpfr-3.1.2/include  conftest.c >&5
In file included from /home/enge/.guix-profile/include/stdio.h:27:0,
                 from conftest.c:24:
/home/enge/.guix-profile/include/features.h:232:36: error: "_XOPEN_SOURCE" is not defined [-Werror=undef]
 #if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) >= 500) && \
                                    ^
/home/enge/.guix-profile/include/features.h:247:30: error: "_POSIX_C_SOURCE" is not defined [-Werror=undef]
 #if defined _POSIX_SOURCE || _POSIX_C_SOURCE >= 1 || defined _XOPEN_SOURCE
                              ^
/home/enge/.guix-profile/include/features.h:255:6: error: "_POSIX_C_SOURCE" is not defined [-Werror=undef]
 #if (_POSIX_C_SOURCE - 0) >= 199309L
      ^
/home/enge/.guix-profile/include/features.h:259:6: error: "_POSIX_C_SOURCE" is not defined [-Werror=undef]
 #if (_POSIX_C_SOURCE - 0) >= 199506L
      ^
/home/enge/.guix-profile/include/features.h:263:6: error: "_POSIX_C_SOURCE" is not defined [-Werror=undef]
 #if (_POSIX_C_SOURCE - 0) >= 200112L
      ^
/home/enge/.guix-profile/include/features.h:271:6: error: "_POSIX_C_SOURCE" is not defined [-Werror=undef]
 #if (_POSIX_C_SOURCE - 0) >= 200809L
      ^
cc1: all warnings being treated as errors
configure:13035: $? = 1
configure: failed program was:
...
configure:13035: result: no
configure:13035: checking locale.h presence
configure:13035: gcc -std=gnu99 -E -I/usr/local/gmp-6.0.0a/include -I/usr/local/mpfr-3.1.2/include  conftest.c
configure:13035: $? = 0
configure:13035: result: yes
configure:13035: WARNING: locale.h: present but cannot be compiled
configure:13035: WARNING: locale.h:     check for missing prerequisite headers?
configure:13035: WARNING: locale.h: see the Autoconf documentation
configure:13035: WARNING: locale.h:     section "Present But Cannot Be Compiled"
configure:13035: WARNING: locale.h: proceeding with the compiler's result


and so on for other header files.


When compiling pari/gp, I get messages such as
/home/enge/.guix-profile/bin/gcc  -c -I. -I../src/headers -I../src/language -I/usr/include -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer  -Wextra -Wno-missing-field-initializers  -o gp_rl.o ../src/gp/gp_rl.c
In file included from /usr/include/features.h:323:0,
                 from /usr/include/stdlib.h:25,
                 from ../src/headers/pari.h:18,
                 from ../src/gp/gp_rl.c:19:
/usr/include/bits/predefs.h:27:0: warning: "__STDC_IEC_559__" redefined [enabled by default]
 #define __STDC_IEC_559__  1
 ^
In file included from <command-line>:0:0:
/home/enge/.guix-profile/include/stdc-predef.h:41:0: note: this is the location of the previous definition
 # define __STDC_IEC_559__  1
 ^

Andreas

Re: Installing a C tool chain

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sat, Apr 05, 2014 at 10:44:55PM +0200, Ludovic Courtès wrote:
>> Comments welcome!

[...]

> When I do a "./configure" of mpc, none of the standard headers are recognised;
> I obtain something like:
>
> configure:12920: checking for ANSI C header files
> configure:13024: result: yes
> configure:13035: checking locale.h usability
> configure:13035: gcc -std=gnu99 -c -g -Werror -g -std=c99 -pedantic -Wno-long-long -Wall -Wextra -Wdeclaration-after-statement -Wundef -Wshadow -Wmissing-prototypes -Wno-unused-value -Wlogical-op -I/usr/local/gmp-6.0.0a/include -I/usr/local/mpfr-3.1.2/include  conftest.c >&5
> In file included from /home/enge/.guix-profile/include/stdio.h:27:0,
>                  from conftest.c:24:
> /home/enge/.guix-profile/include/features.h:232:36: error: "_XOPEN_SOURCE" is not defined [-Werror=undef]
>  #if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) >= 500) && \

This is because you’re compiling with -Wundef -Werror, something that
libc 2.19 headers apparently don’t support.

Can you try without -Werror?

Ludo’.

Re: Installing a C tool chain

[Andreas Enge]

On Mon, Apr 14, 2014 at 09:16:31PM +0200, Ludovic Courtès wrote:
> This is because you’re compiling with -Wundef -Werror, something that
> libc 2.19 headers apparently don’t support.

I tried without both, and then it works. Do you have a source and suggestion
on what to do in such a case? Is it deprecated to use -Werror with the
autotoools?

Pari/GP now also works without modifying anything; maybe this was just a
problem of needing to start a new shell, as sometimes new binaries in the path
are not taken into account due to caching.

Andreas

Re: Installing a C tool chain

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Mon, Apr 14, 2014 at 09:16:31PM +0200, Ludovic Courtès wrote:
>> This is because you’re compiling with -Wundef -Werror, something that
>> libc 2.19 headers apparently don’t support.
>
> I tried without both, and then it works. Do you have a source and suggestion
> on what to do in such a case?

All I know is that feature test macros have been cleaned up in 2.19, so
perhaps it led to a change in behavior.

> Is it deprecated to use -Werror with the autotoools?

In general, using -Werror is very risky, because a slight change in a
third-party header, or in compiler warnings, can cause the project to
fail to build.  In Guile building with -Werror is opt-in for this
reason.

Cheers,
Ludo’.

Re: Installing a C tool chain

[Sergio Durigan Junior]

On Monday, April 14 2014, Ludovic Courtès wrote:

>> Is it deprecated to use -Werror with the autotoools?
>
> In general, using -Werror is very risky, because a slight change in a
> third-party header, or in compiler warnings, can cause the project to
> fail to build.  In Guile building with -Werror is opt-in for this
> reason.

In GDB we use it by default, and it generally does a good service for us
without causing headaches, but of course, as Ludo said, this is mostly a
project's decision.  However, I wouldn't say that using -Werror is
deprecated :-).

-- 
Sergio

Re: [PATCH 1/3] gnu: libxft: Propagate input.

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> * gnu/packages/xorg.scm (libxft): Propagate input libxrender.

Can you please provide the rationale in a comment next to it?

Thanks,
Ludo’.

[PATCH 1/2] gnu: libxft: Propagate input.

[John Darrington]

* gnu/packages/xorg.scm (libxft): Propagate input libxrender.
---
 gnu/packages/xorg.scm |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm
index dfdd82c..c230654 100644
--- a/gnu/packages/xorg.scm
+++ b/gnu/packages/xorg.scm
@@ -1257,10 +1257,12 @@ tracking.")
           (base32
             "1gdv6559cdz1lfw73x7wsvax1fkvphmayrymprljhyyb5nwk5kkz"))))
     (build-system gnu-build-system)
+    (propagated-inputs
+      `(("libxrender" ,libxrender))) ;; libxft refers to symbols in libxrender, 
+                                     ;; so without it, applications cannot be built.
     (inputs
       `(("libx11" ,libx11)
         ("xproto" ,xproto)
-        ("libxrender" ,libxrender)
         ("freetype" ,freetype)
         ("fontconfig" ,fontconfig)))
     (native-inputs
-- 
1.7.10.4

Re: [PATCH 1/2] gnu: libxft: Propagate input.

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> +    (propagated-inputs
> +      `(("libxrender" ,libxrender))) ;; libxft refers to symbols in libxrender, 
> +                                     ;; so without it, applications cannot be built.

The only reasons I can think of where we may want to propagate are when:

  • installed C headers (or .scm, or Perl files, etc.) refer to headers
    of another library;

  • a .pc file lists another .pc in its ‘Requires’ field.

Here the problem seem to be a link-time error in some other program,
right?  Could you post the details?

I’m asking because it could be that the problem lies elsewhere, and I
want to make sure we’re not overlooking something.

Thanks,
Ludo’.

Re: [PATCH 1/2] gnu: libxft: Propagate input.

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> John Darrington <jmd@gnu.org> skribis:
>
>> +    (propagated-inputs
>> +      `(("libxrender" ,libxrender))) ;; libxft refers to symbols in libxrender, 
>> +                                     ;; so without it, applications cannot be built.
>
> The only reasons I can think of where we may want to propagate are when:
>
>   • installed C headers (or .scm, or Perl files, etc.) refer to headers
>     of another library;
>
>   • a .pc file lists another .pc in its ‘Requires’ field.

As we discussed on IRC, the reason is that xft.pc refers to ‘xrender’,
so I just put that in the comment.

Ludo’.