octave-maintainers
[Top][All Lists]
Advanced

[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 22:38:47 +0100
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)

John W. Eaton wrote:
On  4-Nov-2009, Søren Hauberg wrote:

| I'm just following this from the side-line, so this is probably a stupid
| question...  What is 'libtool' supposed to do here? Is it just supposed
| generate a set of compiler and linker flags that ensures that the .oct
| file can be generated? If so, are these flags the same every time
| 'mkoctfile' is called? If so, can't we just generate these flags when
| Octave is compiled instead of generating them at run-time?

I don't know the reasoning behind the design choices that resulted in
rules like

  LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
          --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
          $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)

  .c.lo:
          depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\
          $(LTCOMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
          $(am__mv) $$depbase.Tpo $$depbase.Plo

etc., and embedding the logic for precisely how to compile a source
file or assemble a library inside the libtool script instead of
exposing that logic directly in the Makefile (via apropriate
automake/autoconf macros, for example).  I don't see that this
question is directly answered in the libtool documentation.  Maybe
this question should be directed tothe autoconf/automake/libtool
developers?

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?)

You have to tell libtool which additional libraries to link to, you have to tell libtool which {C|CPP|CXX|LD}FLAGS to use, you have to tell libtool via -I and -L where to search for files. So it does not ease your work here, and instead of a makefile rule like

%.c : %.o
        $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<

foo.dll : $(FOO_OBJ)
        $(CC) -shared $(LDFLAGS) $(LIBS) -o $@ $^

you end up with makefile rules which are fairly more complex and hard to reason.

Besides, did you actually take a look at the code in libtool?
I find it utterly confusing, complex, hard to understand and even harder to use. If I compare it to octave's current makefiles, then these are much cleaner, clearer and easier to adapt and maintain. They do not require any of the confusing logic embedded in libtool. And - most important of all - they work!

However, consider the alternative of eliminating the libtool script in
favor of having the logic of the libtool script exposed in the
Makefile itself.  Then to use that logic in the mkoctfile script, we
would have to duplicate it.  But the Makefile rules would not be
exactly what we need.  This is the situation we have now with Octave's
current build system.  So it makes some sense to avoid the duplication
and just put the logic in a single script that can be called from a
Makefile or some other script.

Ok, my view is surely limited to windows platform, but I don't see the necessity to use all the logic that libtool uses (logic? what logic?), so there's no need in duplicating it, so that is not really a good argument to promote the use of libtool, IMO.
Libtool actually complicates matters, not simplifies them.
The mingw port of the gnu compiler is resposible for taking care of providing the correct flags to GNU ld, collecting the right crt libraries and system-specific object files. There is no extra compiler flag necesary to build a shared library, and there is no extra link flag execpt for "-shared". The gcc/binutils suite does a good job at this.
libtool does not add anything there so I fail to see the gain in its use.

benjamin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]