[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool and mkoctfile
From: |
Jaroslav Hajek |
Subject: |
Re: libtool and mkoctfile |
Date: |
Wed, 4 Nov 2009 18:44:00 +0100 |
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
- libtool and mkoctfile, John W. Eaton, 2009/11/02
- Re: libtool and mkoctfile, Thomas Weber, 2009/11/03
- Re: libtool and mkoctfile, Benjamin Lindner, 2009/11/04
- Re: libtool and mkoctfile, Jaroslav Hajek, 2009/11/04
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/04
- Re: libtool and mkoctfile,
Jaroslav Hajek <=
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/04
- Re: libtool and mkoctfile, Benjamin Lindner, 2009/11/04
- Re: libtool and mkoctfile, Marco Atzeri, 2009/11/04
- Re: libtool and mkoctfile, Benjamin Lindner, 2009/11/04
- Re: libtool and mkoctfile, Marco Atzeri, 2009/11/05
- Re: libtool and mkoctfile, Benjamin Lindner, 2009/11/05
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/04
- Re: libtool and mkoctfile, Abdelrazak Younes, 2009/11/08
- Re: libtool and mkoctfile, Benjamin Lindner, 2009/11/04
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/04