Re: libtool and mkoctfile

[Benjamin Lindner]

John W. Eaton 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

Well, it's a wrapper for "system". I cannot really expect octave to 
include a binary of every program a user might call using "system", can I?

> Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also
> depend on external programs.  Are these all "native Windows" programs?

That depends on which flavor of tar you have installed.
Cygwin tar? Msys Tar? No these are not native versions.
gnuwin32 tar? (don't know if such a thing exists) This would be a native 
version.

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

If an executable does not call native windows api but instead calls e.g. 
a posix intermediate layer which translates these calls to windows api 
calls, then this executable is not native.
Cygwin provides a posix layer for windows, so a cygwin application is 
not native in this sense.
Msys provides a posix layer for windows, so a msys application is again 
not native in this sense.

Wine is a native unix application, but the application requiring wine to 
run isn't.

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

No you don't. You need a compiler/linker, but you cannot get past that. 
But you don't need anything else.
And creating an oct file is basically a simple one-line statement, which 
 - given the experience - a user can call himself. mkoctfile.exe adds 
some convenience, as adding octave's include and library directories and 
provides octave's numerical libraries if you need them, and supports you 
when creating mex files. So it makes life a bit easier for the user.

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

Yes, but to execute it, you need a shell interpreter, which you don't 
have in the first place in windows.
If I distribute a batch script, then it's also "just a batch script", 
but you won't be able to execute it on a *nix system unless you get a 
window command line interpreter.

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

But none of these points are necessary for mkoctfile, are they?

Isn't it rather sarcastic, that a library as gnulib which aims at 
portability requires you to use libtool to get it built, which is 
anyting but portable?

We are always assuming that one builds octave with a gcc compiler. How 
about msvc or e.g. the intel compilers? Are they supported by libtool?

benjamin