gnulib and automake

[John W. Eaton-3]

Instead of the current ad-hoc way of including portability and
replacement functions (things like mkdir, rmdir, strftime, etc.) in
Octave, I would like to start using functions from gnulib
(http://www.gnu.org/software/gnulib).  By using gnulib, we should get
improved portability and in some cases better or newer versions of
some of the replacement functions that we are currently using.

To see what would be required, I started trying to modify Octave's
configure scripts to use gnulib, but quickly found that it is fairly
complex to use gnulib without also using automake.

I've resisted using automake in the past because it seemed that it
would be a fairly large job to convert Octave's existing build
environment.  But at this point, I'm willing to give it a try just to
get gnulib working.

Switching to automake and using gnulib may mean some additional
disruption in building Octave during the transition.  Some changes to
the way Octave is built from the Mercurial archive may be needed.  At
the very least, you will need to have some way to get modules from
gnulib if you don't already have them.  But the rules for this should
all be in the configure (or bootstrap/autogen.sh) script, so you
should really only need a network connection, and then only if you
don't already have the necessary modules.

Are there any strong objections to making this change?

Is anyone on the list an expert automake user who would be willing to
help with the transition?

Thanks,

jwe

[Benjamin Lindner]

John W. Eaton wrote:

> Instead of the current ad-hoc way of including portability and
> replacement functions (things like mkdir, rmdir, strftime, etc.) in
> Octave, I would like to start using functions from gnulib
> (http://www.gnu.org/software/gnulib).  By using gnulib, we should get
> improved portability and in some cases better or newer versions of
> some of the replacement functions that we are currently using.
>
> To see what would be required, I started trying to modify Octave's
> configure scripts to use gnulib, but quickly found that it is fairly
> complex to use gnulib without also using automake.
>
> I've resisted using automake in the past because it seemed that it
> would be a fairly large job to convert Octave's existing build
> environment.  But at this point, I'm willing to give it a try just to
> get gnulib working.
>
> Switching to automake and using gnulib may mean some additional
> disruption in building Octave during the transition.  Some changes to
> the way Octave is built from the Mercurial archive may be needed.  At
> the very least, you will need to have some way to get modules from
> gnulib if you don't already have them.  But the rules for this should
> all be in the configure (or bootstrap/autogen.sh) script, so you
> should really only need a network connection, and then only if you
> don't already have the necessary modules.
>
> Are there any strong objections to making this change?
>
> Is anyone on the list an expert automake user who would be willing to
> help with the transition?

The topic does not seem to have aroused much interest...
Well, I am not an expert on automake and neither on gnulib so I'm not in
the position to state objections.

I'd like to see the build process still work for windows/mingw platform.
Some of octave's dependecy libraries use automake, so this seems to work
all right. I have no experience with gnulib and windows, so I can't
really judge on that.

benjamin

[John W. Eaton-3]

On 26-Oct-2009, Benjamin Lindner wrote:

| John W. Eaton wrote:
| > Instead of the current ad-hoc way of including portability and
| > replacement functions (things like mkdir, rmdir, strftime, etc.) in
| > Octave, I would like to start using functions from gnulib
| > (http://www.gnu.org/software/gnulib).  By using gnulib, we should get
| > improved portability and in some cases better or newer versions of
| > some of the replacement functions that we are currently using.
| >
| > To see what would be required, I started trying to modify Octave's
| > configure scripts to use gnulib, but quickly found that it is fairly
| > complex to use gnulib without also using automake.
| >
| > I've resisted using automake in the past because it seemed that it
| > would be a fairly large job to convert Octave's existing build
| > environment.  But at this point, I'm willing to give it a try just to
| > get gnulib working.
| >
| > Switching to automake and using gnulib may mean some additional
| > disruption in building Octave during the transition.  Some changes to
| > the way Octave is built from the Mercurial archive may be needed.  At
| > the very least, you will need to have some way to get modules from
| > gnulib if you don't already have them.  But the rules for this should
| > all be in the configure (or bootstrap/autogen.sh) script, so you
| > should really only need a network connection, and then only if you
| > don't already have the necessary modules.
| >
| > Are there any strong objections to making this change?
| >
| > Is anyone on the list an expert automake user who would be willing to
| > help with the transition?
|
| The topic does not seem to have aroused much interest...
| Well, I am not an expert on automake and neither on gnulib so I'm not in
| the position to state objections.
|
| I'd like to see the build process still work for windows/mingw platform.
| Some of octave's dependecy libraries use automake, so this seems to work
| all right. I have no experience with gnulib and windows, so I can't
| really judge on that.

I have no intention of breaking the build on Windows systems.

A preliminary changeset for the switch to automake is now available
here:

  http://jweaton.org/automake.gz

It would be helpful if you (and others) could try building Octave with
this changeset and see what happens.  Here's what you need to do:

  * download the changeset

  * clone a copy of the current hg archive

  * cd to the top-level directory of the cloned archive and use "hg
    import" to apply the changeset

  * run ./autogen.sh, configure, and make

To build from the mercurial archive, you will now need to have
automake and libtool installed in addition to the other tools (bison,
flex, gperf, etc.) that were required previously.

Building from a distribution tar file should not require any
additional tools beyond what is currently required.

Some things that have changed:

  * Compilation is handled by libtool, so dependency information is
    generated at compile time and the problem of bad or missing
    dependencies causing make to mysteriously exit should be gone.

  * There are fewer Makefiles.  All of libcruft is built from one
    Makefile now.  All of the scripts directory tree is handled by a
    single Makefile now.

  * Lists of files in the subdirectories (for example, in the libcruft
    and scripts directory trees) are listed in module.mk files
    in those directories.

  * Some of the lists of files (for example, the lists of mx- and vx-
    files in the liboctave subdirectory) are now generated when
    autogen.sh runs instead of being generated by a script when Make
    runs.  This is done because automake needs to see a complete list
    of explicit file names.

  * Many, but not all GNU Makeisms have been removed from the
    Makefiles.  I may have gone too far, or maybe others would prefer
    it if the Makefiles were more portable.  I like to be fairly
    concise, but I would also be willing to work toward portability of
    the Makefiles if others think that is useful.  There is certainly
    more cleanup work that could be done.

  * The Octave version information is no longer extracted from
    src/version.h, but instead stored in configure.ac and inserted
    into src/version.h at build time.

Unresolved issues:

  * Building of .oct files is now done with libtool, which creates the
    dynamically loadable file and a .la file.  The .la file contains
    the name of the dynamically loadable library.  To generate the
    .oct file, we now extract the name from the .la file and link (at
    build time) or rename (at istall time) the dynamically loadable
    file to the .oct file.  The mkoctfile script has not been updated
    to use this method.  Once it is, I think we can delete all the
    hand-crafted shared library stuff from configure.ac.  But before
    we do that, we need to make sure that this all works properly on
    Windows and OS X systems.

  * When linking the final Octave exectuable, libtool generates a
    src/octave script which handles all the details of LD_LIBRARY_PATH
    so that Octave can run in the build directory.  The run-octave
    script no longer does that job.  Instead, it simply sets things
    like the load path and the info ile directory and calls the
    src/octave script.  However, since src/octave is a script, we
    can't run gdb or valgrind on it as before, so debugging with
    "run-octave -g" is currently broken.  I'd like to fix this, but I
    don't know what the best solution is.  The generated src/octave
    script doesn't seem to have a way to handle running a debugger on
    the real executable file.  What do other libtool-based projects
    do?

Comments or suggestions?

I would prefer to solve any problems before checking in this
change, so please help me out by testing this changeset on Windows and
OS X systems.  But I don't want to delay forever, so if I don't get
any feedback in the next week or so, I'll assume that it is working
and check it in.

Once this change is checked in, I will start to look at using gnulib
to handle portability and replacement functions.

jwe

[shaiay]

On Wed, Oct 28, 2009 at 6:12 PM, John W. Eaton <jwe@...> wrote:

> On 26-Oct-2009, Benjamin Lindner wrote:
>
> | John W. Eaton wrote:
> | > Instead of the current ad-hoc way of including portability and
> | > replacement functions (things like mkdir, rmdir, strftime, etc.) in
> | > Octave, I would like to start using functions from gnulib
> | > (http://www.gnu.org/software/gnulib).  By using gnulib, we should get
> | > improved portability and in some cases better or newer versions of
> | > some of the replacement functions that we are currently using.
> | >
> | > To see what would be required, I started trying to modify Octave's
> | > configure scripts to use gnulib, but quickly found that it is fairly
> | > complex to use gnulib without also using automake.
> | >
> | > I've resisted using automake in the past because it seemed that it
> | > would be a fairly large job to convert Octave's existing build
> | > environment.  But at this point, I'm willing to give it a try just to
> | > get gnulib working.
> | >
> | > Switching to automake and using gnulib may mean some additional
> | > disruption in building Octave during the transition.  Some changes to
> | > the way Octave is built from the Mercurial archive may be needed.  At
> | > the very least, you will need to have some way to get modules from
> | > gnulib if you don't already have them.  But the rules for this should
> | > all be in the configure (or bootstrap/autogen.sh) script, so you
> | > should really only need a network connection, and then only if you
> | > don't already have the necessary modules.
> | >
> | > Are there any strong objections to making this change?
> | >
> | > Is anyone on the list an expert automake user who would be willing to
> | > help with the transition?
> |
> | The topic does not seem to have aroused much interest...
> | Well, I am not an expert on automake and neither on gnulib so I'm not in
> | the position to state objections.
> |
> | I'd like to see the build process still work for windows/mingw platform.
> | Some of octave's dependecy libraries use automake, so this seems to work
> | all right. I have no experience with gnulib and windows, so I can't
> | really judge on that.
>
> I have no intention of breaking the build on Windows systems.
>
> A preliminary changeset for the switch to automake is now available
> here:
>
>  http://jweaton.org/automake.gz
>

I get a 404 No found error for this URL

Shai

[John W. Eaton-3]

On 28-Oct-2009, Shai Ayal wrote:

| > A preliminary changeset for the switch to automake is now available
| > here:
| >
| >  http://jweaton.org/automake.gz
| >
| I get a 404 No found error for this URL

Oops, it is http://jweaton.org/automake-diffs.gz

jwe

[Marco atzeri-3]

--- Mer 28/10/09, John W. Eaton <jwe@...> ha scritto:

>
> I would prefer to solve any problems before checking in
> this
> change, so please help me out by testing this changeset on
> Windows and
> OS X systems.  But I don't want to delay forever, so
> if I don't get
> any feedback in the next week or so, I'll assume that it is
> working
> and check it in.
>
> Once this change is checked in, I will start to look at
> using gnulib
> to handle portability and replacement functions.
>
> jwe
>

Hi John,
I need the "no match operator on mx-inlines.cc"

http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-October/009667.html

solved, before trying the new build on cygwin

Thanks
Marco


     

[John W. Eaton-3]

On 28-Oct-2009, Marco Atzeri wrote:

| I need the "no match operator on mx-inlines.cc"
|
| http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-October/009667.html
|
| solved, before trying the new build on cygwin

Can you determine precisely which patch it was that introduced this
problem?

jwe

[Søren Hauberg]

ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
> A preliminary changeset for the switch to automake is now available

After running, './autogen.sh', './configure
--prefix=/home/sh/Programmer' and 'make' I get the following output:

        make  all-recursive
        make[1]: Entering directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
        Making all in libcruft
        make[2]: Entering directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
        make[2]: *** No rule to make target `cacai.lo', needed by
        `libcruft.la'.  Stop.
        make[2]: Leaving directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
        make[1]: *** [all-recursive] Error 1
        make[1]: Leaving directory
        `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
        make: *** [all] Error 2

I don't know what that means :-(

Søren

[John W. Eaton-3]

On 28-Oct-2009, Søren Hauberg wrote:

| ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
| > A preliminary changeset for the switch to automake is now available
|
| After running, './autogen.sh', './configure
| --prefix=/home/sh/Programmer' and 'make' I get the following output:
|
|         make  all-recursive
|         make[1]: Entering directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
|         Making all in libcruft
|         make[2]: Entering directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
|         make[2]: *** No rule to make target `cacai.lo', needed by
|         `libcruft.la'.  Stop.
|         make[2]: Leaving directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
|         make[1]: *** [all-recursive] Error 1
|         make[1]: Leaving directory
|         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
|         make: *** [all] Error 2
|
| I don't know what that means :-(

What version of automake are you using?

jwe

[Søren Hauberg]

ons, 28 10 2009 kl. 14:37 -0400, skrev John W. Eaton:

> On 28-Oct-2009, Søren Hauberg wrote:
>
> | ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
> | > A preliminary changeset for the switch to automake is now available
> |
> | After running, './autogen.sh', './configure
> | --prefix=/home/sh/Programmer' and 'make' I get the following output:
> |
> |         make  all-recursive
> |         make[1]: Entering directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
> |         Making all in libcruft
> |         make[2]: Entering directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
> |         make[2]: *** No rule to make target `cacai.lo', needed by
> |         `libcruft.la'.  Stop.
> |         make[2]: Leaving directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
> |         make[1]: *** [all-recursive] Error 1
> |         make[1]: Leaving directory
> |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
> |         make: *** [all] Error 2
> |
> | I don't know what that means :-(
>
> What version of automake are you using?

'automake --version' gives me

        automake (GNU automake) 1.10.2
        Copyright (C) 2008 Free Software Foundation, Inc.
        License GPLv2+: GNU GPL version 2 or later
        <http://gnu.org/licenses/gpl.html>
        This is free software: you are free to change and redistribute
        it.
        There is NO WARRANTY, to the extent permitted by law.
       
        Written by Tom Tromey <tromey@...>
               and Alexandre Duret-Lutz <adl@...>.

Søren

[John W. Eaton-3]

On 28-Oct-2009, Søren Hauberg wrote:

| ons, 28 10 2009 kl. 14:37 -0400, skrev John W. Eaton:
| > On 28-Oct-2009, Søren Hauberg wrote:
| >
| > | ons, 28 10 2009 kl. 12:12 -0400, skrev John W. Eaton:
| > | > A preliminary changeset for the switch to automake is now available
| > |
| > | After running, './autogen.sh', './configure
| > | --prefix=/home/sh/Programmer' and 'make' I get the following output:
| > |
| > |         make  all-recursive
| > |         make[1]: Entering directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
| > |         Making all in libcruft
| > |         make[2]: Entering directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
| > |         make[2]: *** No rule to make target `cacai.lo', needed by
| > |         `libcruft.la'.  Stop.
| > |         make[2]: Leaving directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake/libcruft'
| > |         make[1]: *** [all-recursive] Error 1
| > |         make[1]: Leaving directory
| > |         `/home/sh/Dokumenter/octave/octave-hg/upstream-automake'
| > |         make: *** [all] Error 2
| > |
| > | I don't know what that means :-(
| >
| > What version of automake are you using?
|
| 'automake --version' gives me
|
|         automake (GNU automake) 1.10.2
|         Copyright (C) 2008 Free Software Foundation, Inc.
|         License GPLv2+: GNU GPL version 2 or later
|         <http://gnu.org/licenses/gpl.html>
|         This is free software: you are free to change and redistribute
|         it.
|         There is NO WARRANTY, to the extent permitted by law.
|        
|         Written by Tom Tromey <tromey@...>
|                and Alexandre Duret-Lutz <adl@...>.

OK.  I have 1.11, and I don't have this problem.  Does automake 1.10.2
support the option

  AUTOMAKE_OPTIONS = subdir-objects

?  If not, I think we will have to require automake 1.11.

Ah, I see the following note in the NEWS file for automake 1.11:

  * Languages changes:

    - subdir-object mode works now with Fortran (F77, FC, preprocessed
      Fortran, and Ratfor).

so I guess 1.11 is required.

jwe

[Søren Hauberg]

ons, 28 10 2009 kl. 14:45 -0400, skrev John W. Eaton:

> OK.  I have 1.11, and I don't have this problem.  Does automake 1.10.2
> support the option
>
>   AUTOMAKE_OPTIONS = subdir-objects
>
> ?  If not, I think we will have to require automake 1.11.
>
> Ah, I see the following note in the NEWS file for automake 1.11:
>
>   * Languages changes:
>
>     - subdir-object mode works now with Fortran (F77, FC, preprocessed
>       Fortran, and Ratfor).
>
> so I guess 1.11 is required.

Okay, I guess I'll have to wait for this to be packaged for Ubuntu. It
should be part of the next release that's coming in a couple of days, so
this is not a big issue for me.

Søren

[shaiay]

On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe@...> wrote:

> On 28-Oct-2009, Shai Ayal wrote:
>
> | > A preliminary changeset for the switch to automake is now available
> | > here:
> | >
> | >  http://jweaton.org/automake.gz
> | >
> | I get a 404 No found error for this URL
>
> Oops, it is http://jweaton.org/automake-diffs.gz

It almost compiles for me except at the very end:

./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
@otherbackslash ->@let \=@realbackslash

@xrdef #1#2->{@indexnofonts @turnoffactive
                                           @xdef @safexrefname {#1}}@expanda...
l.4743 @xrdef{doc-getenv-pg}{567}

No pages of output.
Transcript written on octave.log.
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[3]: *** [octave.dvi] Error 1
make[3]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/shaia/hack/octave-amake/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/shaia/hack/octave-amake'
make: *** [all] Error 2

I attach the doc/interpreter/octave.log file

[Rik-3]

When running autogen.sh I get

calling libtoolize...
Remember to add `AC_PROG_LIBTOOL' to `configure.ac'.

and a little further down

calling automake...
libcruft/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
libcruft/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
libcruft/Makefile.am:26:   to `configure.ac' and run `aclocal' and
`autoconf' again.
libcruft/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
make sure
libcruft/Makefile.am:26:   its definition is in aclocal's search path.
liboctave/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
liboctave/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
liboctave/Makefile.am:26:   to `configure.ac' and run `aclocal' and
`autoconf' again.
liboctave/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
make sure
liboctave/Makefile.am:26:   its definition is in aclocal's search path.
src/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
src/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
src/Makefile.am:26:   to `configure.ac' and run `aclocal' and `autoconf'
again.
src/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
src/Makefile.am:26:   its definition is in aclocal's search path.

autogen.sh appears to succeed, but the next step of configure fails with

./configure: line 16887: syntax error near unexpected token `disable-static'
./configure: line 16887: `LT_INIT(disable-static)'

Adding AC_PROG_LIBTOOL to configure.ac silenced the warnings but did not
fix the issue with configure.

System is Linux Kubuntu 8.04.
automake-1.10
autoconf-2.61
libtool-1.5.26

--Rik

[John W. Eaton-3]

On 28-Oct-2009, Shai Ayal wrote:

| On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe@...> wrote:
| > On 28-Oct-2009, Shai Ayal wrote:
| >
| > | > A preliminary changeset for the switch to automake is now available
| > | > here:
| > | >
| > | >  http://jweaton.org/automake.gz
| > | >
| > | I get a 404 No found error for this URL
| >
| > Oops, it is http://jweaton.org/automake-diffs.gz
| It almost compiles for me except at the very end:
| ./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
| @otherbackslash ->@let \=@realbackslash
|
| @xrdef #1#2->{@indexnofonts @turnoffactive
|                                            @xdef @safexrefname {#1}}@expanda...
| l.4743 @xrdef{doc-getenv-pg}{567}

Does the following change fix the problem for you?


diff --git a/doc/interpreter/Makefile.am b/doc/interpreter/Makefile.am
--- a/doc/interpreter/Makefile.am
+++ b/doc/interpreter/Makefile.am
@@ -31,6 +31,9 @@
 TEXINPUTS = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)"
 export TEXINPUTS
 
+TEXMFCNF = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)"
+export TEXMFCNF
+
 dist_man1_MANS = \
   mkoctfile.1 \
   octave-bug.1 \


jwe

[John W. Eaton-3]

On 28-Oct-2009, Rik wrote:

| When running autogen.sh I get
|
| calling libtoolize...
| Remember to add `AC_PROG_LIBTOOL' to `configure.ac'.
|
| and a little further down
|
| calling automake...
| libcruft/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
| libcruft/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
| `AC_PROG_LIBTOOL'
| libcruft/Makefile.am:26:   to `configure.ac' and run `aclocal' and
| `autoconf' again.
| libcruft/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
| make sure
| libcruft/Makefile.am:26:   its definition is in aclocal's search path.
| liboctave/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
| liboctave/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
| `AC_PROG_LIBTOOL'
| liboctave/Makefile.am:26:   to `configure.ac' and run `aclocal' and
| `autoconf' again.
| liboctave/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac',
| make sure
| liboctave/Makefile.am:26:   its definition is in aclocal's search path.
| src/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined
| src/Makefile.am:26:   The usual way to define `LIBTOOL' is to add
| `AC_PROG_LIBTOOL'
| src/Makefile.am:26:   to `configure.ac' and run `aclocal' and `autoconf'
| again.
| src/Makefile.am:26:   If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
| src/Makefile.am:26:   its definition is in aclocal's search path.
|
| autogen.sh appears to succeed, but the next step of configure fails with
|
| ./configure: line 16887: syntax error near unexpected token `disable-static'
| ./configure: line 16887: `LT_INIT(disable-static)'
|
| Adding AC_PROG_LIBTOOL to configure.ac silenced the warnings but did not
| fix the issue with configure.
|
| System is Linux Kubuntu 8.04.

It runs cleanly for me.

| automake-1.10

Given what Søren Hauberg said earlier, this version is apparently too
old.  You need 1.11.  I already added a requirement for 1.11 in
configure.ac.

| libtool-1.5.26

I also have

  $ libtool --version
  ltmain.sh (GNU libtool) 2.2.6
  Written by Gordon Matzigkeit <gord@...>, 1996

so maybe 1.5.26 is also too old?  For now, I've added

  LT_PREREQ([2.2.6])

to configure.ac since that version is known to work, but could relax
that a bit if someone with an older version of libtool confirms that
it works without problems.

jwe

[shaiay]

On Wed, Oct 28, 2009 at 9:49 PM, John W. Eaton <jwe@...> wrote:

> On 28-Oct-2009, Shai Ayal wrote:
>
> | On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe@...> wrote:
> | > On 28-Oct-2009, Shai Ayal wrote:
> | >
> | > | > A preliminary changeset for the switch to automake is now available
> | > | > here:
> | > | >
> | > | >  http://jweaton.org/automake.gz
> | > | >
> | > | I get a 404 No found error for this URL
> | >
> | > Oops, it is http://jweaton.org/automake-diffs.gz
> | It almost compiles for me except at the very end:
> | ./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
> | @otherbackslash ->@let \=@realbackslash
> |
> | @xrdef #1#2->{@indexnofonts @turnoffactive
> |                                            @xdef @safexrefname {#1}}@expanda...
> | l.4743 @xrdef{doc-getenv-pg}{567}
>
> Does the following change fix the problem for you?
>
>
> diff --git a/doc/interpreter/Makefile.am b/doc/interpreter/Makefile.am
> --- a/doc/interpreter/Makefile.am
> +++ b/doc/interpreter/Makefile.am
> @@ -31,6 +31,9 @@
>  TEXINPUTS = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)"
>  export TEXINPUTS
>
> +TEXMFCNF = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)"
> +export TEXMFCNF
> +
>  dist_man1_MANS = \
>   mkoctfile.1 \
>   octave-bug.1 \
>

Now the error is:
Making all in interpreter
make[1]: Entering directory `/home/shaia/hack/octave-amake/doc/interpreter'
../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'png');"
Makefile:582: *** Recursive variable `TEXMFCNF' references itself
(eventually).  Stop.
make[1]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
make: *** [all-recursive] Error 1

[John W. Eaton-3]

On 28-Oct-2009, Shai Ayal wrote:

| On Wed, Oct 28, 2009 at 9:49 PM, John W. Eaton <jwe@...> wrote:
| > On 28-Oct-2009, Shai Ayal wrote:
| >
| > | On Wed, Oct 28, 2009 at 7:07 PM, John W. Eaton <jwe@...> wrote:
| > | > On 28-Oct-2009, Shai Ayal wrote:
| > | >
| > | > | > A preliminary changeset for the switch to automake is now available
| > | > | > here:
| > | > | >
| > | > | >  http://jweaton.org/automake.gz
| > | > | >
| > | > | I get a 404 No found error for this URL
| > | >
| > | > Oops, it is http://jweaton.org/automake-diffs.gz
| > | It almost compiles for me except at the very end:
| > | ./octave.aux:4743: TeX capacity exceeded, sorry [save size=5000].
| > | @otherbackslash ->@let \=@realbackslash
| > |
| > | @xrdef #1#2->{@indexnofonts @turnoffactive
| > |                                            @xdef @safexrefname {#1}}@expanda...
| > | l.4743 @xrdef{doc-getenv-pg}{567}
| >
| > Does the following change fix the problem for you?
| >
| >
| > diff --git a/doc/interpreter/Makefile.am b/doc/interpreter/Makefile.am
| > --- a/doc/interpreter/Makefile.am
| > +++ b/doc/interpreter/Makefile.am
| > @@ -31,6 +31,9 @@
| >  TEXINPUTS = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)"
| >  export TEXINPUTS
| >
| > +TEXMFCNF = "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)"
| > +export TEXMFCNF
| > +
| >  dist_man1_MANS = \
| >   mkoctfile.1 \
| >   octave-bug.1 \
| >
|
| Now the error is:
| Making all in interpreter
| make[1]: Entering directory `/home/shaia/hack/octave-amake/doc/interpreter'
| ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'png');"
| Makefile:582: *** Recursive variable `TEXMFCNF' references itself
| (eventually).  Stop.
| make[1]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
| make: *** [all-recursive] Error 1

Try taking $(TEXMFCNF) out of the right hand side of that assignment,
or use := instead of = as the assignment operator.  I'm not sure what
the best solution is.  How often do people have TEXMFCNF set in the
environment?  OTOH, GNU Make accepts :=, but I don't think it is
portable (if we decide that matters).

jwe

[Judd Storrs]

On Wed, Oct 28, 2009 at 3:49 PM, John W. Eaton <jwe@...> wrote:
| Does the following change fix the problem for you?

On Wed, Oct 28, 2009 at 4:14 PM, Shai Ayal <shaiay@...> wrote:
> Now the error is:
> Making all in interpreter
> make[1]: Entering directory `/home/shaia/hack/octave-amake/doc/interpreter'
> ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'png');"
> Makefile:582: *** Recursive variable `TEXMFCNF' references itself
> (eventually).  Stop.
> make[1]: Leaving directory `/home/shaia/hack/octave-amake/doc/interpreter'
> make: *** [all-recursive] Error 1

I'm seeing the same (Ubuntu 9.10rc). I don't know if it's related to
the TeX memory error but prior to adding the TEXMFCNF change (but with
automake-diff applied), I noticed many errors flying by that look like
this:

        rm -rf $backupdir; exit $rc
../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'eps');"

../../run-octave -f -q -H -p . --eval "geometryimages ('triplot', 'eps');"

../../run-octave -f -q -H -p . --eval "geometryimages ('griddata', 'eps');"

../../run-octave -f -q -H -p . --eval "geometryimages ('convhull', 'eps');"

Output completed.  Verifying that all points are below 7.4e-15 of
all facets.  Will make 7381 distance computations.

multiplot> plot "-" binary format='%float64' record=62 using ($1):($2)
axes x1y1 title "" with lines linestyle 1 , "-" binary
format='%float64' record=121 using ($1):($2) axes x1y1 title "" with
linestyle 2 ;


                                                                ^
           line 0: expecting 'lines', 'points', 'linespoints', 'dots',
'impulses',
        'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
        'histeps', 'filledcurves', 'boxes', 'boxerrorbars', 'boxxyerrorbars',
        'vectors', 'financebars', 'candlesticks', 'errorlines', 'xerrorlines',
        'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
         'image', 'rgbimage'


multiplot> f�?ffffff���]#rp�?
            ^
           line 0: invalid character


multiplot> �?�����������”��?
           ^
           line 0: invalid character

[John W. Eaton-3]

On 28-Oct-2009, Judd Storrs wrote:

| I'm seeing the same (Ubuntu 9.10rc). I don't know if it's related to
| the TeX memory error but prior to adding the TEXMFCNF change (but with
| automake-diff applied), I noticed many errors flying by that look like
| this:
|
| rm -rf $backupdir; exit $rc
| ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'eps');"
|
| ../../run-octave -f -q -H -p . --eval "geometryimages ('triplot', 'eps');"
|
| ../../run-octave -f -q -H -p . --eval "geometryimages ('griddata', 'eps');"
|
| ../../run-octave -f -q -H -p . --eval "geometryimages ('convhull', 'eps');"
|
| Output completed.  Verifying that all points are below 7.4e-15 of
| all facets.  Will make 7381 distance computations.
|
| multiplot> plot "-" binary format='%float64' record=62 using ($1):($2)
| axes x1y1 title "" with lines linestyle 1 , "-" binary
| format='%float64' record=121 using ($1):($2) axes x1y1 title "" with
| linestyle 2 ;
|
|
|                                                                 ^
|            line 0: expecting 'lines', 'points', 'linespoints', 'dots',
| 'impulses',
| 'yerrorbars', 'xerrorbars', 'xyerrorbars', 'steps', 'fsteps',
| 'histeps', 'filledcurves', 'boxes', 'boxerrorbars', 'boxxyerrorbars',
| 'vectors', 'financebars', 'candlesticks', 'errorlines', 'xerrorlines',
| 'yerrorlines', 'xyerrorlines', 'pm3d', 'labels', 'histograms',
| 'image', 'rgbimage'
|
|
| multiplot> f�3u=?ffffff�3u=u=u=]#rp�3u=?
|             ^
|            line 0: invalid character
|
|
| multiplot> �3u=?�3u=u=u=u=u=u=u=u=u=u=u=�u=u=?
|            ^
|            line 0: invalid character

What version of gnuplot do you have?  I recently upgraded and gnuplot
4.2.6 appeared on my system and now I'm seeing a similar problem.
This problem seems to be independent of my automake changes though...
Can you confirm that?  If you have a build using the sources before my
patch, then cd to the doc/interpreter directory in your build tree and
try

  rm -f *.eps
  make

and see if you see similar problems.

jwe