[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
- Re: gnulib and automake, Benjamin Lindner, 2009/10/26
- Re: gnulib and automake,
John W. Eaton <=
- Re: gnulib and automake, Shai Ayal, 2009/10/28
- Re: gnulib and automake, John W. Eaton, 2009/10/28
- Re: gnulib and automake, Shai Ayal, 2009/10/28
- Re: gnulib and automake, John W. Eaton, 2009/10/28
- Re: gnulib and automake, Shai Ayal, 2009/10/28
- Re: gnulib and automake, John W. Eaton, 2009/10/28
- Re: gnulib and automake, Shai Ayal, 2009/10/29
- Re: gnulib and automake, Judd Storrs, 2009/10/28
- Re: gnulib and automake, John W. Eaton, 2009/10/28
- Re: gnulib and automake, Judd Storrs, 2009/10/28