Re: libtool and mkoctfile

[Jaroslav Hajek]

On Wed, Nov 4, 2009 at 9:50 AM, Benjamin Lindner <address@hidden> wrote:
>
>> I would like to make the mkoctfile script use libtool to create .oct
>> files, the same as we will soon be using in the Makefiles that build
>> the .oct files that are part of Octave.  I think I have most of the
>> details worked out, but one problem remains.  Libtool is a Unix shell
>> script, so we will need to do something for Windows systems.  Is it
>> reasonable for Octave to require a Unix command shell and the
>> associated commands that libtool requires for building .oct files?
>
> Frankly, no. I'd like to return the question by asking is it *really* 
> necessary to rely on a unix-sh-interpreter?
> I see mkoctfile as an integral part of Octave an if mkoctfile requires a 
> unix-layer to run, then, well, you won't have a native windows binary any 
> more.
> And I wouldn't see the point in providing mingw binaries with the additional 
> necessity of a unix shell, when there's cygwin available which does exactly 
> all this, and I guess much better.
> And what about msvc? There are no 'official' binaries, but octave can still 
> be built with ms compilers I guess and run as native binary.
>
> What about the future development, what about e.g. x64 binaries?
> I'm not sure about unix-shells-for-win64-which-are-not-cygwin. Possibly 
> cygwin is the better choice as unix layer - and then I'll end up again at the 
> question, why provide mingw32/64 along with a unix shell interpreter when 
> there is cygwin?
>
> Aside from the question of unix-sh-interpreter yes or no, I disagree to using 
> libtool, at least for windows platform. Simply because libtool does not work 
> properly for windows.
> There are problems creating shared libs, there are problems with compiler 
> flags, there are problems with libtool dropping libraries from the command 
> line at own gusto, there are problems with shared libstdc++.
> So I would most probably end up packaging a patched (i.e. hacked) version of 
> libtool which I honestly could not support because i simply don't understand 
> it myself.
> Using libtool for building octave is using it in a controlled, and kind of 
> encapsuled environment where one knows the odds and ends and where you have a 
> bunch of workaround tricks in your pocket.
> But distributing it and depending on it in open space, I believe will end up 
> with many reports of "mkoctfile does not work for me" and us saying, "yes, we 
> know, this is libtool".
>
>> If not, then I suppose that when Octave is built, we could try to
>> extract from libtool the commands that it would run, and embed those
>> in the mkoctfile script/program, though I'm not sure how to do that in
>> a reliable way.  If we do go this route, then I would like to consider
>> again eliminating the mkoctfile script and keeping only the C++
>> program.  Having both seems like asking for trouble as the two are
>> likely to get out of sync.
>>
>> It seems easier to me to just package a Unix shelland the necessary
>> commands for Windows systems, then eliminate the C++ version of
>> mkoctfile.
>
> I'd like to stick to the C++ version of mkoctfile and I would have no problem 
> with having a (windows) C++ version alongside the (common) shell version. You 
> are right about having two versions and them possibly diverging, but how much 
> development in the future do you honstly see in mkoctfile? How much new 
> features do you plan to add to mkoctfile? I think that the additional effort 
> of keeping the C++ version in pace with the shell version small compared to 
> forcing a shell/libtool version for windows and maintaining it.
> I'd rather be one step behind with the C++ version than requiring a unix 
> shell for it.
>
> To me, the C++ interface is octave's biggest bonus aside of it being free 
> software. And to be able to use the C++ interface natively with a free 
> compiler available on windows, I wouldn't want to miss that.
>
>> If you object to including a Unix shell, why?
>
> I'd object to having a unix shell as runtime requirement for octave. It'd end 
> up in a windows binary depending on a unix layer, and that's cygwin.
>
>> Suppose that libtool
>> were written in Perl.  Would you also object to including perl in the
>> distribution so that Octave could run the libtool script?
>
> Possibly. I have no experience with perl distributions for windows, so I 
> cannot estimate the amount of effort it would require to include it.
> I'd probably stick to a C++ version of mkoctfile anyway.
>
> This is also getting a bit philosophical.
>
> At the current stage, windows binaries of octave do not require any 
> privileges for installing a default user (who is not administrator) on 
> windows doesn't have.
> It even doesn't require being "installed" at all, you can just copy it and 
> run it off a usb stick, if you like. It doesn't need to fiddle with windows 
> registry and it can be cleanly uninstalled or removed by simply deleting the 
> directory tree it was installed to.
>
> Now beginning to add dependencies that don't follow this philosophy, may mean 
> that octave is no longer portable, and octave must strictly be installed with 
> administrative privileges. And this is IMO the wrong way to go.
>
>> Octave
>> already includes a perl function.  Do we distribute a copy of Perl
>> with Octave on Windows systems so that the perl function can work?
>
> No, perl's not included. Now I'm curious. Which octave function is that?
>
> benjamin
> --

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.

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.

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.

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