On Feb 23, 2011, at 15:14, Bruce Korb wrote: > * guile should provide autoconf macros to do checking, > like for wrong version headers.
That seems like a good idea, but unless all the other packages' header directories have already been added to the include path by the time this test is run, it's not foolproof. And of course another package would be in exactly the same boat -- if Guile's check comes last, the Foo package can't be sure that adding Guile's header directory (if we add them at the front -- but even if we add them at the tail, they'll come before /usr/include) isn't going to break things. If the library ABI is tweaked to code the version into a symbol name, this test could become a simple compile-and-link test. Of course, that approach has other issues, like getting backwards-compatible library upgrades to work without recompiling applications. I vaguely remember reading an argument years back for including individual headers by pathname, rather than building up potentially long lists of directories and then searching all of them for each header. So "--with-foo-dir=/x/y/z" means you should include "/x/y/z/include/foo.h", not "foo.h" with "-I/x/y/z/include" given to the compiler and a prayer offered up that you don't have a foo.h installed anywhere else. I didn't spend much time thinking about pros and cons of such an approach. It sounds like it would address this one problem fairly nicely, but I suspect other new problems would come up. > * Developers should be clearly warned that -I/usr/local/include > needs to be after all other -I options, due to guile > header naming conflicts. Again, this problem isn't unique to Guile -- and we can't put *all* packages' -I options first; somebody's gotta go second/third/.../last. > * I have to vary various interfaces because of the > obsolescence that happens from release to release. > Consistency would be really nice: > > There should be a macro that has the value 0x200000 or > some such that includes the revision number, too. > "scm_init_guile_with_version_check" would just ignore > the last 12 bits (or divide by 1000, whatever works...) I've seen this approach used elsewhere, and it seems like a good idea. Configure-time feature tests are great and all, but some features are subtle to test for, and some packages don't use configure scripts that can do feature tests. OpenSSL even encodes an extra digit for development version vs beta or release; I'm not sure if we need to go that far. Ken