Re: libtool and mkoctfile

[Benjamin Lindner]

> 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
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01