[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool and mkoctfile
From: |
Benjamin Lindner |
Subject: |
Re: libtool and mkoctfile |
Date: |
Wed, 04 Nov 2009 09:50:58 +0100 |
> 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
- libtool and mkoctfile, John W. Eaton, 2009/11/02
- Re: libtool and mkoctfile, Thomas Weber, 2009/11/03
- Re: libtool and mkoctfile,
Benjamin Lindner <=
- 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, 2009/11/04
- 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