octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib and automake


From: John W. Eaton
Subject: Re: gnulib and automake
Date: Wed, 28 Oct 2009 12:12:42 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]