Re: libtool and mkoctfile

[Benjamin Lindner]

> 
> Okay, from my viewpoint of Debian maintainer: I would jump for joy when
> Octave uses libtool.
> 
> In fact, two or three years ago I looked into adding libtool to Octave,
> but I gave up when I realized that Octave didn't use automake (which is
> not strictly necessary, but the libtool manual only documents the
> automake use case).
> 
> libtool is not some esoteric tool, but sort of standard for libraries in
> the Unix-like world. Using such a tool means you can ask on normal
> distribution lists and there will be literally hundreds of people with
> experience on this topic.  Whereas currently it means asking on the
> Octave lists and hoping that the few people here have an idea. Which, I
> might add, usually boils down to John in use cases like Solaris. Thus,
> I'd actually expect people to give him free reign in his decision or
> stand up and help the next time a question about Solaris comes up.

I believe I stated that it's John's decision 
to move octave's build system to libtool and I'll respect
his decision.
I will try to walk along for the windows platform.
I cannot yet tell if it will work, and I am not sure if
I'd want to support the (maybe exclusively for windows) 
increased complexity, when cygwin provides much better 
supported posix compatibility and unix-way-of-life for
windows.

In a way libtool appeared esoteric to me. It does all sorts
of strage things, complexly interwoven internally,
supports some of gcc's flags, some not, decides which 
libraries to accept and which not (at own gusto?), doesn't 
tell you really what it's thinking, and then presents
you with its decision not to create the library
you asked for. And that happening for a gnu compiler and for
a gnu compiler's library. That's were it is getting strange,
and I haven't been able to follow libtool's resoning yet.
Perhaps if one understands the internals, one will
quickly know where to intercept.

I admit that I do not rejoyce if octave moves to libtool. 
For the windows platform it adds complexity, and currently 
does not work.
But hey that's only me, so be it.

> Now, some things that came up in different mails in the thread, by
> different people:
> 
> | For windows it simply doesn't make any sense to use it, just to get
> | source code compiled and linked. Creating an oct file is a one-liner
> | with the gnu compiler, and using a nearly-300K sized shell script to do
> | the job seems - well - strange?
> 
> Yes, it takes one line. And it takes one line on Linux. And one line on
> Solaris. And one line on HP-UX. 
> Unfortunately, these lines might differ on all of these systems. They
> might differ when using a different compiler. They might differ when
> using a different toolchain. Does anybody on this list know how to
> compile a shared library on VMS? I don't. But libtool does.
> 
> http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html
> to get an idea of the fiddling required.

Granted. Neither do I know. 
But this is - and I realise that this is a very egocentric 
point of view - no real bonus if for the one platform I use
it does not. And it's some fiddling to get it working on 
windows. 
It's a cool tool if it works, but if it doesn't
it is getting really complex.

> | 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.
> 
> I already had to patch mkoctfile to make it work reliable in Debian (it
> hardcodes paths when building Octave, which makes up for problems when
> the compiler is updated). So, no, mkoctfile is not a simple
> one-size-fits-all solution.
> 
> Is libtool better? I don't know. But there are certainly more people
> with knowledge about libtool than there are with knowledge about
> mkoctfile and compiler flags.
> 
> | With all due respect, but at this point I'd like to re-raise the
> | question, why are you trying to switch to libtool in the first place?
> | What's so complex about compiling a source file and linking a library
> | supposing for simplicity one is using the gnu compiler/linker suite?
> | (Does libtool even support different compilers?)
> 
> I can only wonder that people argue about portability in one sentence,
> yet don't care about totally different compilers and platforms in the
> other sentences. You want portability? Use proven tools. And yes,
> libtool is complex and actually pretty slow when run. The fact that it's
> still around after all these years should however be a sign that
> somehow, it's deemed useful.

Yes that may be so.

libtool's mingw history is short - the first release for
msys environment is from august this year. gnuwin32's 
version is 1.5.26 (feb-2008) and there have been no 
updates yet. Maybe for good reason, I don't know.

So if it wouldn't be for msys's version I'd probably had 
to build it myself, and I'm not sure I'd call it proven then.

I realise that my view is rather narrow-focused with
respect to interoperability and different platforms.
And that my reactions have been - well - emotional.
I apologize, I did not intend to discredit either persons
or platforms.

I guess windows is the one system which is out of line.
Wouldn't be the first time for that.
And it's also still around after all these years.

libtool appears like a big multifunctional too which 
aims to support many or possibly all types of screws,
ones commonly used, other maybe more exotic or rare.
It comes highly recommended for its plurality and 
I see that many people use it. 

And now I find that for the particular type of screw I
use, it does not fit. And I play around a bit,
at the end of the day I get a bit irritated. 
And I start to ask myself why use this tool when 
there is a nice adapter available, or a small 
screwdriver at hand which does very nicely.

Again: I'm not exactly a fan of libtool on windows. 
I respect John's decision, I will try to get it working.
It doesn't make it easier, rather the other way round.
I am honestly not sure about mkoctfile as shell script 
with libtool for windows.

benjamin

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01