guile-lib - devel branch - patch 4 of 11

guile-lib - devel branch - patch 4 of 11

[David Pirotte]

[-- Attachment #1.1: Type: text/plain, Size: 42 bytes --]

guile-lib - devel branch - patch 4 of 11

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0004-Updating-autogen-and-configure.patch --]
[-- Type: text/x-patch, Size: 5109 bytes --]

From d6f82af4e61f17ac2c4e6291e31d64cf86dc834d Mon Sep 17 00:00:00 2001
From: David Pirotte <david@altosw.be>
Date: Tue, 12 Jul 2016 21:21:07 -0300
Subject: [PATCH 04/11] Updating autogen and configure

* autogen.sh: (a) removing the call to configure, printing an invitation
  to do so instead; (b) creating build-aux/config.rpath if it does not
  exists: this because we use configure.ac uses the guile.m4 GUILE_FLAGS
  macro, among others, which needs this file, not installed anymore by
  modern version of automake, iiuc, and without it, autogen raises an
  an error. For why it's needed, see the comments in m4/guile.m4.

* configure.ac: Adding a copyright; bumping prereq -> 2.69, version ->
  0.2.3-dev; let's use build-aux, m4; automake -> 1.14, serial-tests;
  checks/looks for guile 2.2, 2.0; cleaning HAVE_GUILE_COMPILE checks,
  we always have access to a compiler: in the end this wil disappear,
  but we kept and set HAVE_GUILE_COMPILE=1 still used 'en aval'; calling
  GUILE_GLOBAL_SITE_DIR and GUILE_SITE_CCACHE_DIR, we'll use them in
  Makefile.am.
---
 autogen.sh   | 13 ++++++++-
 configure.ac | 89 ++++++++++++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 84 insertions(+), 18 deletions(-)

diff --git a/autogen.sh b/autogen.sh
index 9b1b118..ef75c8e 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -7,5 +7,16 @@ set -e
 echo '@setfilename guile-library.info' > doc/guile-library.texi
 touch -d 'jan 23 1980' doc/guile-library.texi
 
+# configure.ac uses the guile.m4 GUILE_FLAGS macro, among others,
+# which needs build-aux/config.rpath which is not installed anymore by
+# modern version of automake, and without it, this script will raise
+# an error. For why it's needed, see the comments wtr in m4/guile.m4.
+if [ ! -d "build-aux" ]; then
+    mkdir build-aux
+fi
+touch build-aux/config.rpath
+
 autoreconf -vif
-exec ./configure "$@"
+
+echo
+echo "Now run ./configure --prefix=/your/prefix."
diff --git a/configure.ac b/configure.ac
index d694f48..710ce5a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,32 +1,87 @@
 dnl -*- Autoconf -*-
+dnl
+dnl   configuration script for Guile-Lib
+dnl   Process this file with autoconf to produce configure.
+dnl
 
-AC_INIT(guile-lib, 0.2.2)
+define(GUILE_LIB_CONFIGURE_COPYRIGHT,[[
+
+Copyright (C) 2016 David Pirotte
+David Pirotte <david at altosw dot be>
+
+This file is part of Guile-Lib.
+
+Guile-Lib is free software: you can redistribute it, as a whole,
+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.
+
+Each Guile-Lib module contained in Guile-Lib has its own copying
+conditions, specified in the comments at the beginning of the
+module's source file.
+
+Guile-Lib 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 Guile-Lib.  If not, see
+<http://www.gnu.org/licenses/>.
+
+]])
+
+AC_PREREQ(2.69)
+
+AC_INIT(
+  [guile-lib],
+  [0.2.3-dev],
+  [guile-devel at gnu dor org])
+
+AC_CONFIG_AUX_DIR([build-aux])
+AC_CONFIG_MACRO_DIR([m4])
+
+dnl Use `serial-tests' so the output `check-guile' is not hidden
+dnl (`parallel-tests' is the default in Automake 1.13.)
+dnl `serial-tests' was introduced in Automake 1.12.
+AM_INIT_AUTOMAKE([1.14 gnu -Wall -Wno-portability -Wno-syntax \
+  color-tests serial-tests foreign])
+AM_MAINTAINER_MODE([enable])
+AM_SILENT_RULES([yes])
+
+AC_COPYRIGHT(GUILE_LIB_CONFIGURE_COPYRIGHT)
 AC_CONFIG_SRCDIR(src/md5.scm)
-AM_INIT_AUTOMAKE([1.11 gnu check-news color-tests -Wall -Wno-portability])
 
 AC_SUBST(ACLOCAL_FLAGS,$ACLOCAL_FLAGS)
 
-GUILE_PROGS
+GUILE_PKG([2.2 2.0])
+dnl must be changed to 2.0.12 before to release it needs recent
+dnl stable-2.0 texinfo patches so 'make check' pass. I'm using git so
+dnl I have all these patches locally, however 2.0.11 distro would
+dnl fail.
+GUILE_PROGS([2.0.11])
+GUILE_SITE_DIR
+GUILE_GLOBAL_SITE_DIR
+GUILE_SITE_CCACHE_DIR
 GUILE_FLAGS
 
-if $GUILE_TOOLS | grep compile 2>&1 >/dev/null; then
-   GUILE_COMPILE="$GUILE_TOOLS compile"
-   HAVE_GUILE_COMPILE=1
-else
-   GUILE_COMPILE=""
-   HAVE_GUILE_COMPILE=0
-fi
-
+dnl this should disappear
+dnl but for now we'll keep it, it's used 'en aval'
+HAVE_GUILE_COMPILE=1
+GUILE_COMPILE="guild compile"
 AC_SUBST(GUILE_COMPILE)
 AM_CONDITIONAL(HAVE_GUILE_COMPILE, test "$HAVE_GUILE_COMPILE" = 1)
 
+AC_CONFIG_FILES(
+  [dev-environ],
+  [chmod +x dev-environ])
+
 AC_CONFIG_FILES([
-Makefile
-src/Makefile
-doc/Makefile
-examples/Makefile
-unit-tests/Makefile
+  Makefile
+  src/Makefile
+  doc/Makefile
+  examples/Makefile
+  unit-tests/Makefile
 ])
-AC_CONFIG_FILES([dev-environ], [chmod +x dev-environ])
 
 AC_OUTPUT
-- 
2.8.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: guile-lib - devel branch - patch 4 of 11

[Eli Zaretskii]

> Date: Fri, 15 Jul 2016 22:43:05 -0300
> From: David Pirotte <david@altosw.be>
> 
> * configure.ac: Adding a copyright; bumping prereq -> 2.69

Why is that a good idea?  Are there any features Guile needs that
older versions don't support?

Thanks.

Re: guile-lib - devel branch - patch 4 of 11

[David Pirotte]

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

Hi Eli,

	nice to see progress on MinGW, congrat!

> > * configure.ac: Adding a copyright; bumping prereq -> 2.69  

> Why is that a good idea?

Why not? 
2.69 is the latest stable, available since April 2012

>  Are there any features Guile needs that older versions don't support?

It is not a just question of feature, but about running the same version [or higher]
then the one used to check, distcheck... Why would we want to even try to support any
previous version but the latest stable here?

I don't.

Autotool chain related issue/bugs can be very tedious to track down and solve, and
requiring users to install the latest stable versions, guarantee they won't have any
surprise on that side, and saves us precious time, we have other things to do.

IMO, it is the right thing to do.

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: guile-lib - devel branch - patch 4 of 11

[Eli Zaretskii]

> Date: Sat, 16 Jul 2016 17:34:02 -0300
> From: David Pirotte <david@altosw.be>
> Cc: guile-devel@gnu.org
> 
> 	nice to see progress on MinGW, congrat!

Thanks.

> > > * configure.ac: Adding a copyright; bumping prereq -> 2.69  
> 
> > Why is that a good idea?
> 
> Why not? 
> 2.69 is the latest stable, available since April 2012
> 
> >  Are there any features Guile needs that older versions don't support?
> 
> It is not a just question of feature, but about running the same version [or higher]
> then the one used to check, distcheck... Why would we want to even try to support any
> previous version but the latest stable here?

Because people might have older versions installed, and it's a
nuisance to have to upgrade unrelated tools in your development
environment just because you need to build a newer version of Guile.
Besides, other packages might required older versions.

> Autotool chain related issue/bugs can be very tedious to track down and solve, and
> requiring users to install the latest stable versions, guarantee they won't have any
> surprise on that side, and saves us precious time, we have other things to do.

If there are known problems with older versions that get in the way, I
agree.  Are there?

If there are no known problems that interfere with maintaining Guile,
I think refraining from the above will be nicer to our users.

Re: guile-lib - devel branch - patch 4 of 11

[David Pirotte]

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

Hello Eli,

> > 2.69 is the latest stable, available since April 2012

> If there are known problems with older versions that get in the way, I
> agree.  Are there?

Are there?

> Because people might have older versions installed, and it's a nuisance to have to
> upgrade unrelated tools in your development environment just because you need to
> build a newer version of Guile.

I would not qualify autoconf/automake of 'unrelated' but 'essential' tools, and
would never call 'nuisance' the fact that you ask a user to be in the 'conditions'
that guarantee a proper build. I can not guarantee this proper build with earlier
versions, I don't have time neither any wish to maintain older version of these
essential tools.

> Besides, other packages might required older versions.

Are you aware of any incompatibilities between 2.69 and earlier 2.x version(s) of
autoconf?

David.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: guile-lib - devel branch - patch 4 of 11

[Eli Zaretskii]

> Date: Sun, 17 Jul 2016 17:26:35 -0300
> From: David Pirotte <david@altosw.be>
> Cc: guile-devel@gnu.org
> 
> > > 2.69 is the latest stable, available since April 2012
> 
> > If there are known problems with older versions that get in the way, I
> > agree.  Are there?
> 
> Are there?

That's what I asked.  Do you know the answer?

> > Because people might have older versions installed, and it's a nuisance to have to
> > upgrade unrelated tools in your development environment just because you need to
> > build a newer version of Guile.
> 
> I would not qualify autoconf/automake of 'unrelated' but 'essential' tools, and
> would never call 'nuisance' the fact that you ask a user to be in the 'conditions'
> that guarantee a proper build. I can not guarantee this proper build with earlier
> versions, I don't have time neither any wish to maintain older version of these
> essential tools.

We already guaranteed a proper build with older versions, since Guile
builds now with whatever minimal versions we were requiring.  So this
problem does not exist, and will not exist, unless we deliberately
start using a newer version.

> > Besides, other packages might required older versions.
> 
> Are you aware of any incompatibilities between 2.69 and earlier 2.x version(s) of
> autoconf?

That's not the point.  If a package requires a certain version, my
best bet is to use that version.

And some packages (e.g., GDB) indeed require use of a specific version
in order to make sure changes in the derived files are consistent.

Re: guile-lib - devel branch - patch 4 of 11

[David Pirotte]

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

Hello,

> > > > 2.69 is the latest stable, available since April 2012  

> > > If there are known problems with older versions that get in the way, I
> > > agree.  Are there?  

> > Are there?  

> That's what I asked.  Do you know the answer?

Don't you understand? How could I possibly answer that quiz, since it's been 4 years
I use 2.69? You can't tell for sure just because there has been no complain: you can
only tell for sure if someone you 'trust' check with what ever version you'd like to
use.

I have no interest here, but if you do check and guarantee it works, I happy to
trust you.

> > > Besides, other packages might required older versions.  

> > Are you aware of any incompatibilities between 2.69 and earlier 2.x version(s) of
> > autoconf?  

> That's not the point.

It is exactly the point sorry.  Besides, when a package requires an earlier version
then the latest stable, which is the case for Guile-Clutter for example, then
developers should provide a guidance for users, on how to exactly locally install
earlier then stable versions in a way that it does not interfere with the rest of
the system.

Besides, 'users' who locally manually install and compile GDB probably know a lot
more then I on the subject :) And I bet they all setup a specific environment for
that..

If they do not have a specific environment, these advanced 'users' [you mean top
notch hackers right?] know they can locally edit our configure.ac file and try what
ever version of autoconf they have... It will most probably work, I agree with you,
but I'm not interested to try and offer guarantee...

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: guile-lib - devel branch - patch 4 of 11

[Eli Zaretskii]

> Date: Tue, 19 Jul 2016 20:53:44 -0300
> From: David Pirotte <david@altosw.be>
> Cc: guile-devel@gnu.org
> 
> > > > > 2.69 is the latest stable, available since April 2012  
> 
> > > > If there are known problems with older versions that get in the way, I
> > > > agree.  Are there?  
> 
> > > Are there?  
> 
> > That's what I asked.  Do you know the answer?
> 
> Don't you understand? How could I possibly answer that quiz, since it's been 4 years
> I use 2.69? You can't tell for sure just because there has been no complain: you can
> only tell for sure if someone you 'trust' check with what ever version you'd like to
> use.

Problems in past versions of development tools are described in the
documentation, and if that's not enough, the maintainers of the tools
can be asked about them.  There should be no need to learn about that
from personal experience alone.

> Besides, 'users' who locally manually install and compile GDB probably know a lot
> more then I on the subject :)

I don't think the fact that I build my own GDB means my time is cheap
and should be disregarded.

> And I bet they all setup a specific environment for that..

Not necessarily.  E.g., I don't.

Once again, if we must use features that exist only in a newer
version, then it's a reason good enough to request users to upgrade.
But as long as no such features are required, doing this:

  AC_PREREQ(2.69)

even though an older version would do, is IMO not a good idea.

And if you still disagree, let's leave it at that.  I'm not speaking
for the Guile project, so my opinion can be easily overridden.

Thanks.

Re: guile-lib - devel branch - patch 4 of 11

[David Pirotte]

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

Hello Eli,

> > Don't you understand? How could I possibly answer that quiz, since it's been 4
> > years I use 2.69? You can't tell for sure just because there has been no
> > complain: you can only tell for sure if someone you 'trust' check with what ever
> > version you'd like to use.  

> Problems in past versions of development tools are described in the
> documentation, and if that's not enough, the maintainers of the tools
> can be asked about them.  There should be no need to learn about that
> from personal experience alone.

I totally disagree with your last sentence, as a consequence of both what I've been
teached and what my experience 'told' me. So, if you have a well isolated
environment using an earlier version of autoconf and automake 1.14, I'll trust you.

Besides, should I agree with you, but I don't, I still have absolutely no time and no
interest to read about a 5y doc and ask maintainers quiz about 5y old version of
these tools.

> > Besides, 'users' who locally manually install and compile GDB probably know a lot
> > more then I on the subject :)  

> I don't think the fact that I build my own GDB means my time is cheap
> and should be disregarded.

I never implied that, this is a very unfair statement: you are the one who ask me to
spend my time to read and talk to maintainers about a more then 4y tool and doc.

At the very most, all you have to do is to locally edit the guile-lib configure.ac
and change AC_PREREQ(2.69) to what ever version you use and 'pass':  that does take
any time.

>   AC_PREREQ(2.69)
> 
> even though an older version would do, is IMO not a good idea.

This has nothing to do with an 'idea', it's about what we can guarantee: as I said
above, it's not ok for me to 'just' read, and if you can test 'make distcheck' and
tells me it's ok, using an earlier version of autoconf and automake 1.14, I'll trust
you.

> And if you still disagree, let's leave it at that.  I'm not speaking
> for the Guile project, so my opinion can be easily overridden.

I don't speak in the name of Guile either, I am contributor. Note that this 
is Guile-Lib, not Guile (not that it would change my position wrt this, but...).

Thanks,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: guile-lib - devel branch - patch 4 of 11

[Andy Wingo]

On Sun 17 Jul 2016 04:36, Eli Zaretskii <eliz@gnu.org> writes:

> If there are known problems with older versions that get in the way, I
> agree.  Are there?
>
> If there are no known problems that interfere with maintaining Guile,
> I think refraining from the above will be nicer to our users.

To be clear this is a third-party package called "guile-lib", not Guile
proper.

Regards,

Andy