Re: SCM_BOOL_T became #nil -- et al. ?

[Ken Raeburn]

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