[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
- Re: libtool and mkoctfile, (continued)
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/06
- Re: libtool and mkoctfile, Jaroslav Hajek, 2009/11/06
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/06
- Re: libtool and mkoctfile, Marco Atzeri, 2009/11/06
- Re: libtool and mkoctfile, Benjamin Lindner, 2009/11/06
Re: libtool and mkoctfile, John W. Eaton, 2009/11/04
Re: libtool and mkoctfile, Søren Hauberg, 2009/11/04
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/04
- Re: libtool and mkoctfile,
Benjamin Lindner <=
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/04
- Re: libtool and mkoctfile, Benjamin Lindner, 2009/11/06
- Re: libtool and mkoctfile, Judd Storrs, 2009/11/06
- Re: libtool and mkoctfile, John W. Eaton, 2009/11/06
- Re: libtool and mkoctfile, Judd Storrs, 2009/11/07