static library dependencies in gideon

[Brian Gold]

> > Could you explain how that works, ie, how to set up libtool to 
> > recognize the dependencies?  My project used libtool for the 
> > building and it never caught the static library dependencies.  I was
> > constantly just deleting my target executable by hand so it was 
> > forced to relink all of the libraries.

> Well, look at kdevelop/lib/sourceinfo/Makefile.am which produces
> a convenience (i.e. static) library which is linked into the shared 
> library in kdevelop/lib. Has worked fine for me.

> Bernd.

A good example.  Try adding "libkdevelop_la_DEPENDENCIES = " to
kdevelop/lib/Makefile.am.  It should stop working. :)

I actually built my "foo" example using libtool to illustrate the
problem.  KDevelop adds the line "foo_DEPENDENCIES = ", and when I touch
bar/bar.cpp, it doesn't relink foo.  Comment out that dependencies line,
and everything works as it should.  Using libtool doesn't solve the
problem.

KDevelop shouldn't just comment out the DEPENDENCIES line, b/c I might
actually want something in there.  I think my earlier fix (WishList item
50762) still applies, even with libtool (but now the libraries are .la
instead of .a).

Libtool is great and versatile, but there are situations where simpler
is better.  New users of KDevelop will likely want the option of a
"plain old .a library", and I think they should have it.  

The project I'm working on has several other developers who more or less
know C++, but are scared to death of automake and autoconf (perhaps
rightfully so ;)).  The "output on the screen" isn't pretty, they say. 
Libtool makes that even worse, and that's why I wanted simple static
libraries.  It's easier for them to understand the output of make/gcc
and correct any errors.  It's an in-house project, so no one else has to
worry about the lack of portability or flexibility in .a's.

Brian