Re: libtool and mkoctfile

[Jaroslav Hajek]

On Wed, Nov 4, 2009 at 4:39 PM, John W. Eaton <address@hidden> wrote:
> 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.
>

Still, I daresay mkoctfile is usually much more important for most
people. People won't expect "zip" to work unless zip is installed.

>
> 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.
>

If thanks to these changes Octave's code will become cleaner and more
portable, then I suppose that justifies them well. I never knew of
gnulib before, so I can't justify that. I hope it's no problem use
libtool and gnulib with other compilers.

One problem I see with gnulib is that it is C-centric rather than C++-centric.
Have you also considered Boost? FSF recognizes the Boost software
license as free and GPL compatible.
Boost likewise provides portable I/O and memory facilities, special
functions etc...
Boost is extensively developed and maintained, and very portable. Some
portions of Boost made it into the C++ standard, and some are planned
in the future. Maybe Boost would be a better option for Octave?

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz