On Tue, 2009-11-17 at 14:13 -0500, al davis wrote: > On Monday 16 November 2009, KURT PETERS wrote: > > What do you intend to use gwave for? Is it for viewing SPICE > > output?
> It's too bad autoconf isn't more helpful at identifying what is > missing. Its not autoconf's fault, it is the developer who didn't write the test. (Not that I'm blaming Steven - a complete suite of useful autoconf tests are something which take time to acquire, and require feedback from those who find them inadequate). If the developer writes decent tests, autoconf produces a nice, meaningful and helpful report of the issue. Usually, the issue is that developers _forget_ to add tests for things they implicitly rely upon. That leads to a failure at compile time, or run-time. It is the compile errors which are usually cryptic and evil to diagnose. (Or the run-time errors, like this one.. what a disgusting back-trace!) > Without autoconf, what files are missing is obvious > when it fails to compile, so I would ask the package manager > what package provides that file, and install that package. With > autoconf, you can look at the log, and see what test failed and > how it failed. With patience, eventually you will find it. If autoconf fails a test and doesn't give meaningful output - that is the developers fault - they probably didn't bother to write a decent error message. The problem here is that it _did not_ fail any tests, the software compiled fine.. it appears to be a run-time issue. (It will be somewhere in the .scm stuff which is not compiled). This could be solved if an autoconf test were written to check that the required run-time bits and pieces were present at build time. Perhaps there is a further complexity though.. if the package builds fine - does it run fine with the build-environment setup - but then fail on a typical user-install (without the -devel packages and any other dependencies they pull in). In that case, the distro package is missing a run-time dependency. For some types (e.g. dynamically linked libraries), the distro package building tools will automatically extract these dependencies from the packaged executables. For stuff like .scm dependencies, that probably fails. I realise Gentoo is somewhat different to other distros (I used to use it for a long time,) where binary packages are distributed, but I recall similar issues regarding dependencies apply. > Unfortunately, I don't remember what the name of the missing > package was, other than that it was different from what autoconf > said it was. As a developer yourself, I assume you filed the bug report about this with the gwave upstream - rather than just ignoring it to perpetuate the myth that some-how this is all autoconf's fault? With gEDA, an auto-conf failure right off at ./configure time due to missing packages is _much_ easier to grok than the piles of compiler puke you get if a -devel package is missing, and as a result some critical type isn't defined in some project global header file. (Damn - I'm in a grumpy mood today - perhaps I should lay off the emails for a bit ;)) Best wishes, Peter C. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user