Derek Atkins <[EMAIL PROTECTED]> writes: > Quoting Thomas Bushnell BSG <[EMAIL PROTECTED]>: > >> What I mean is that *sometimes* they are spurious, not that they >> always are. > > Yeah, but libtool can't tell when they are from when they aren't. > Standard libtool errs in one direction. Debian libtool errs on the > other. In this case Debian Libtool causes the compilation to fail, > because there was an assumption that libtool would keep track of > the dependencies for us. Debian broke that assumption, which is > why it's failing now.
libtool never kept track of dependencies, actually. :) libtool actually can tell. Debian's version does not omit any needed dependencies, in the sense that Debian's version never fails to declare a dependency that ought to be there. "Ought to be there" meaning that A should depend on B when a change in B could necessitate a recompile of A. In the normal case, we have a program P, which links against library L. P depends on L. Also, L links against library Q. P does not use anything from library Q directly; the API of library Q does not affect P at all. But standard libtool goes ahead and declares that P depends on Q. Programs like gnucash have been relying on this behavior in cases where P *does* use the API of Q. You are correct that if you don't declare that P uses the API of Q, then there is no simple way to automatically figure out when P actually needs Q and when it doesn't. But how about this instead: just have P actually declare which libraries it uses and link against them? After all, nobody else but P has the facts necessary to do that. I would be happy to help do this if nobody else in gnucash land wants to, but the current build system is so arcane that I can't figure it out on my own, so I would need help. (I understand that this has been a problem for some time, and that the current crop of developers are not really responsible for the build system's arcanity.) This is a serious problem in any system in which P, L, and Q are packaged separately. Debian has been confronted with cases where hundreds of packages contained spurious dependencies on packages, which all then require coordinated recompilation against the new version of Q, all completely unnecessarily, and costing weeks and weeks of work. Thomas _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
