* [PATCH 1/3] gnu: libxft: Propagate input.
@ 2014-01-23 20:07 John Darrington
2014-01-23 20:07 ` [PATCH 2/3] gnu: fltk: New module John Darrington
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: John Darrington @ 2014-01-23 20:07 UTC (permalink / raw)
To: guix-devel; +Cc: 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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/3] gnu: fltk: New module
2014-01-23 20:07 [PATCH 1/3] gnu: libxft: Propagate input John Darrington
@ 2014-01-23 20:07 ` John Darrington
2014-01-24 16:07 ` Thompson, David
2014-01-23 20:07 ` [PATCH 3/3] gnu: Add octave and dependencies John Darrington
2014-01-24 13:11 ` [PATCH 1/3] gnu: libxft: Propagate input Ludovic Courtès
2 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-23 20:07 UTC (permalink / raw)
To: guix-devel; +Cc: 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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 3/3] gnu: Add octave and dependencies
2014-01-23 20:07 [PATCH 1/3] gnu: libxft: Propagate input John Darrington
2014-01-23 20:07 ` [PATCH 2/3] gnu: fltk: New module John Darrington
@ 2014-01-23 20:07 ` John Darrington
2014-01-25 15:30 ` Ludovic Courtès
2014-01-24 13:11 ` [PATCH 1/3] gnu: libxft: Propagate input Ludovic Courtès
2 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-23 20:07 UTC (permalink / raw)
To: guix-devel; +Cc: 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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 1/3] gnu: libxft: Propagate input.
2014-01-23 20:07 [PATCH 1/3] gnu: libxft: Propagate input John Darrington
2014-01-23 20:07 ` [PATCH 2/3] gnu: fltk: New module John Darrington
2014-01-23 20:07 ` [PATCH 3/3] gnu: Add octave and dependencies John Darrington
@ 2014-01-24 13:11 ` Ludovic Courtès
2014-01-25 7:01 ` [PATCH 1/2] " John Darrington
2 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-24 13:11 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/3] gnu: fltk: New module
2014-01-23 20:07 ` [PATCH 2/3] gnu: fltk: New module John Darrington
@ 2014-01-24 16:07 ` Thompson, David
2014-01-25 7:00 ` [PATCH 2/2] " John Darrington
0 siblings, 1 reply; 37+ messages in thread
From: Thompson, David @ 2014-01-24 16:07 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 2/2] gnu: fltk: New module
2014-01-24 16:07 ` Thompson, David
@ 2014-01-25 7:00 ` John Darrington
2014-01-25 8:27 ` (unknown), John Darrington
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-25 7:00 UTC (permalink / raw)
To: guix-devel; +Cc: 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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 1/2] gnu: libxft: Propagate input.
2014-01-24 13:11 ` [PATCH 1/3] gnu: libxft: Propagate input Ludovic Courtès
@ 2014-01-25 7:01 ` John Darrington
2014-01-25 15:19 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-25 7:01 UTC (permalink / raw)
To: guix-devel; +Cc: 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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* (unknown),
2014-01-25 7:00 ` [PATCH 2/2] " John Darrington
@ 2014-01-25 8:27 ` John Darrington
2014-01-25 8:27 ` [PATCH] gnu: fltk: New module John Darrington
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-25 8:27 UTC (permalink / raw)
To: guix-devel
Sorry! Corrected patch herewith.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH] gnu: fltk: New module
2014-01-25 8:27 ` (unknown), John Darrington
@ 2014-01-25 8:27 ` John Darrington
2014-01-25 15:39 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-25 8:27 UTC (permalink / raw)
To: guix-devel; +Cc: 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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] gnu: libxft: Propagate input.
2014-01-25 7:01 ` [PATCH 1/2] " John Darrington
@ 2014-01-25 15:19 ` Ludovic Courtès
2014-01-25 15:38 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-25 15:19 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-23 20:07 ` [PATCH 3/3] gnu: Add octave and dependencies John Darrington
@ 2014-01-25 15:30 ` Ludovic Courtès
2014-01-25 16:14 ` John Darrington
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-25 15:30 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] gnu: libxft: Propagate input.
2014-01-25 15:19 ` Ludovic Courtès
@ 2014-01-25 15:38 ` Ludovic Courtès
0 siblings, 0 replies; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-25 15:38 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] gnu: fltk: New module
2014-01-25 8:27 ` [PATCH] gnu: fltk: New module John Darrington
@ 2014-01-25 15:39 ` Ludovic Courtès
0 siblings, 0 replies; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-25 15:39 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel
John Darrington <jmd@gnu.org> skribis:
> * gnu/packages/fltk.scm: New file
> * gnu-system.am: New file fltk.scm
Pushed, thanks!
Ludo’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-25 15:30 ` Ludovic Courtès
@ 2014-01-25 16:14 ` John Darrington
2014-01-25 16:42 ` Andreas Enge
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-25 16:14 UTC (permalink / raw)
To: Ludovic Court??s; +Cc: guix-devel, 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-25 16:14 ` John Darrington
@ 2014-01-25 16:42 ` Andreas Enge
2014-01-25 17:04 ` John Darrington
0 siblings, 1 reply; 37+ messages in thread
From: Andreas Enge @ 2014-01-25 16:42 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel, John Darrington
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-25 16:42 ` Andreas Enge
@ 2014-01-25 17:04 ` John Darrington
2014-01-25 20:41 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-25 17:04 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel, 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-25 17:04 ` John Darrington
@ 2014-01-25 20:41 ` Ludovic Courtès
2014-01-26 7:38 ` John Darrington
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-25 20:41 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel, John Darrington
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-25 20:41 ` Ludovic Courtès
@ 2014-01-26 7:38 ` John Darrington
2014-01-26 9:09 ` (unknown), John Darrington
2014-01-26 18:54 ` [PATCH 3/3] gnu: Add octave and dependencies Andreas Enge
0 siblings, 2 replies; 37+ messages in thread
From: John Darrington @ 2014-01-26 7:38 UTC (permalink / raw)
To: Ludovic Court??s; +Cc: guix-devel, 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* (unknown),
2014-01-26 7:38 ` John Darrington
@ 2014-01-26 9:09 ` John Darrington
2014-01-26 9:09 ` [PATCH] gnu: Add gnuplot John Darrington
2014-01-26 18:54 ` [PATCH 3/3] gnu: Add octave and dependencies Andreas Enge
1 sibling, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-26 9:09 UTC (permalink / raw)
To: guix-devel
... 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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH] gnu: Add gnuplot
2014-01-26 9:09 ` (unknown), John Darrington
@ 2014-01-26 9:09 ` John Darrington
2014-01-26 20:17 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-26 9:09 UTC (permalink / raw)
To: guix-devel; +Cc: 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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-26 7:38 ` John Darrington
2014-01-26 9:09 ` (unknown), John Darrington
@ 2014-01-26 18:54 ` Andreas Enge
2014-01-26 19:30 ` Ludovic Courtès
1 sibling, 1 reply; 37+ messages in thread
From: Andreas Enge @ 2014-01-26 18:54 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel, John Darrington
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-26 18:54 ` [PATCH 3/3] gnu: Add octave and dependencies Andreas Enge
@ 2014-01-26 19:30 ` Ludovic Courtès
2014-01-27 8:30 ` John Darrington
2014-01-27 9:04 ` Sree Harsha Totakura
0 siblings, 2 replies; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-26 19:30 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel, John Darrington
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] gnu: Add gnuplot
2014-01-26 9:09 ` [PATCH] gnu: Add gnuplot John Darrington
@ 2014-01-26 20:17 ` Ludovic Courtès
0 siblings, 0 replies; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-26 20:17 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel
John Darrington <jmd@gnu.org> skribis:
> * gnu/packages/maths.scm (gnuplot): New variable
Pushed, thanks!
Ludo’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-26 19:30 ` Ludovic Courtès
@ 2014-01-27 8:30 ` John Darrington
2014-01-27 9:11 ` Ludovic Courtès
2014-01-27 9:04 ` Sree Harsha Totakura
1 sibling, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-27 8:30 UTC (permalink / raw)
To: Ludovic Court??s; +Cc: guix-devel, 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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-26 19:30 ` Ludovic Courtès
2014-01-27 8:30 ` John Darrington
@ 2014-01-27 9:04 ` Sree Harsha Totakura
2014-01-27 9:53 ` Installing a C tool chain Ludovic Courtès
1 sibling, 1 reply; 37+ messages in thread
From: Sree Harsha Totakura @ 2014-01-27 9:04 UTC (permalink / raw)
To: guix-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-27 8:30 ` John Darrington
@ 2014-01-27 9:11 ` Ludovic Courtès
2014-01-29 8:20 ` John Darrington
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-27 9:11 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel, John Darrington
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Installing a C tool chain
2014-01-27 9:04 ` Sree Harsha Totakura
@ 2014-01-27 9:53 ` Ludovic Courtès
2014-01-27 10:32 ` Sree Harsha Totakura
2014-02-04 6:31 ` Mark H Weaver
0 siblings, 2 replies; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-27 9:53 UTC (permalink / raw)
To: Sree Harsha Totakura; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-01-27 9:53 ` Installing a C tool chain Ludovic Courtès
@ 2014-01-27 10:32 ` Sree Harsha Totakura
2014-02-04 6:31 ` Mark H Weaver
1 sibling, 0 replies; 37+ messages in thread
From: Sree Harsha Totakura @ 2014-01-27 10:32 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-27 9:11 ` Ludovic Courtès
@ 2014-01-29 8:20 ` John Darrington
2014-01-29 21:26 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: John Darrington @ 2014-01-29 8:20 UTC (permalink / raw)
To: Ludovic Court??s; +Cc: guix-devel, 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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/3] gnu: Add octave and dependencies
2014-01-29 8:20 ` John Darrington
@ 2014-01-29 21:26 ` Ludovic Courtès
0 siblings, 0 replies; 37+ messages in thread
From: Ludovic Courtès @ 2014-01-29 21:26 UTC (permalink / raw)
To: John Darrington; +Cc: guix-devel, John Darrington
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-01-27 9:53 ` Installing a C tool chain Ludovic Courtès
2014-01-27 10:32 ` Sree Harsha Totakura
@ 2014-02-04 6:31 ` Mark H Weaver
2014-04-05 20:44 ` Ludovic Courtès
1 sibling, 1 reply; 37+ messages in thread
From: Mark H Weaver @ 2014-02-04 6:31 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-02-04 6:31 ` Mark H Weaver
@ 2014-04-05 20:44 ` Ludovic Courtès
2014-04-14 17:54 ` Andreas Enge
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-04-05 20:44 UTC (permalink / raw)
To: Mark H Weaver; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-04-05 20:44 ` Ludovic Courtès
@ 2014-04-14 17:54 ` Andreas Enge
2014-04-14 19:16 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: Andreas Enge @ 2014-04-14 17:54 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-04-14 17:54 ` Andreas Enge
@ 2014-04-14 19:16 ` Ludovic Courtès
2014-04-14 19:43 ` Andreas Enge
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-04-14 19:16 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-04-14 19:16 ` Ludovic Courtès
@ 2014-04-14 19:43 ` Andreas Enge
2014-04-14 21:32 ` Ludovic Courtès
0 siblings, 1 reply; 37+ messages in thread
From: Andreas Enge @ 2014-04-14 19:43 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-04-14 19:43 ` Andreas Enge
@ 2014-04-14 21:32 ` Ludovic Courtès
2014-04-14 21:57 ` Sergio Durigan Junior
0 siblings, 1 reply; 37+ messages in thread
From: Ludovic Courtès @ 2014-04-14 21:32 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Installing a C tool chain
2014-04-14 21:32 ` Ludovic Courtès
@ 2014-04-14 21:57 ` Sergio Durigan Junior
0 siblings, 0 replies; 37+ messages in thread
From: Sergio Durigan Junior @ 2014-04-14 21:57 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2014-04-14 21:58 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-23 20:07 [PATCH 1/3] gnu: libxft: Propagate input John Darrington
2014-01-23 20:07 ` [PATCH 2/3] gnu: fltk: New module John Darrington
2014-01-24 16:07 ` Thompson, David
2014-01-25 7:00 ` [PATCH 2/2] " John Darrington
2014-01-25 8:27 ` (unknown), John Darrington
2014-01-25 8:27 ` [PATCH] gnu: fltk: New module John Darrington
2014-01-25 15:39 ` Ludovic Courtès
2014-01-23 20:07 ` [PATCH 3/3] gnu: Add octave and dependencies John Darrington
2014-01-25 15:30 ` Ludovic Courtès
2014-01-25 16:14 ` John Darrington
2014-01-25 16:42 ` Andreas Enge
2014-01-25 17:04 ` John Darrington
2014-01-25 20:41 ` Ludovic Courtès
2014-01-26 7:38 ` John Darrington
2014-01-26 9:09 ` (unknown), John Darrington
2014-01-26 9:09 ` [PATCH] gnu: Add gnuplot John Darrington
2014-01-26 20:17 ` Ludovic Courtès
2014-01-26 18:54 ` [PATCH 3/3] gnu: Add octave and dependencies Andreas Enge
2014-01-26 19:30 ` Ludovic Courtès
2014-01-27 8:30 ` John Darrington
2014-01-27 9:11 ` Ludovic Courtès
2014-01-29 8:20 ` John Darrington
2014-01-29 21:26 ` Ludovic Courtès
2014-01-27 9:04 ` Sree Harsha Totakura
2014-01-27 9:53 ` Installing a C tool chain Ludovic Courtès
2014-01-27 10:32 ` Sree Harsha Totakura
2014-02-04 6:31 ` Mark H Weaver
2014-04-05 20:44 ` Ludovic Courtès
2014-04-14 17:54 ` Andreas Enge
2014-04-14 19:16 ` Ludovic Courtès
2014-04-14 19:43 ` Andreas Enge
2014-04-14 21:32 ` Ludovic Courtès
2014-04-14 21:57 ` Sergio Durigan Junior
2014-01-24 13:11 ` [PATCH 1/3] gnu: libxft: Propagate input Ludovic Courtès
2014-01-25 7:01 ` [PATCH 1/2] " John Darrington
2014-01-25 15:19 ` Ludovic Courtès
2014-01-25 15:38 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).