Re: libtool and mkoctfile

[John W. Eaton]

On  4-Nov-2009, Jaroslav Hajek wrote:

| The only perl script is octave/mk-opts.pl, and it is only used to
| recreate the option handlers DASPK-opts and similar. I think that like
| awk, bison, flex and gperf, perl is only needed to build from plain
| repo, but not from the distribution tarball.

There is also the perl function in the interpreter:

  `perl' is a function from the file 
/usr/share/octave/3.2.3/m/miscellaneous/perl.m

   -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE)
   -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE, ARGUMENT1,
            ARGUMENT2, ...)
       Invoke perl script SCRIPTFILE with possibly a list of command line
       arguments.  Returns output in OUTPUT and status in STATUS.

       See also: system

Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also
depend on external programs.  Are these all "native Windows" programs?
If you say yes, then what makes something a "native Windows" program?
A POSIX shell interpreter is just another program that interprets a
particular command language.  Isn't the Msys shell a "native Windows"
program?  Is a program written to depend on it not?  I guess I don't
understand where you draw the ine.

In any case, we would not be exposing libtool or the shell to the
Octave user.  So I don't see the problem as anything other than having
to distribute and install some additional programs with binary Octave
distributions.  People installing from source already have all of these
tools.  And you already need extra programs to be able to compile .oct
or .mex files.

| If libtool was only required for generating distrib tarballs, it would
| make little difference, but making it a requirement for mkoctfile
| would mean a significant change. Not just for Windows; unless I'm
| missing something, it would mean that dependency on libtool would be
| required for Octave packages in GNU/Linux distros as well.

Yes, but libtool is just shell script.

| Regarding the question alone (whether to do this or not) I'm yet
| undecided. I need yet to read carefully John's rationale for the move
| to gnulib.

We currently use an odd mixture of old and homegrown code to replace
missing functionality (things like fnmatch, glob, readdir, strftime,
etc.).  Mostly, we've picked up these functions from other packages at
random points in time and rarely update them.  The functions in gnulib
are at least maintained and updated, and mostly better than versions
that we might write ourselves.  By using gnulib, the portability and
replacement functions in Octave will be kept up to date automatically
with little effort on our part.  If there are bugs in these functions,
then we will fix them in gnulib, and then all the users of gnulib will
benefit, not just the users of Octave.

Using gnulib without automake and libtool is just too much effort, so
we really need to switch Octave's build system to use these tools.
There are other benefits to using automake and libtool.  First, we get
correct dependency generation, and it is done simultaneously when
compiling.  Obsolete dependencies are also handled properly, so that
will fix a longstanding bug in Octave's Makefiles.  We get dist and
clean targets in the Makefiles mostly for free.  Dependency tracking
for the configure script and Makefiles is handled correctly.  With a
little more effort, we could also have a build system that doesn't
depend on GNU Make, but I don't see that as a high priority.

Using libtool also has similar advantages to using gnulib.  Rather
than having to reinvent how to deal with shared libraries, we can take
advantage of the knowledge built in to libtool.

If mkoctfile does not use libtool, then we will still have to maintain
the code in Octave's configure script that deals with building shared
libraries.   I'd rather delete all that and avoid duplicating what is
already done by libtool.

jwe