Re: SCM_BOOL_T became #nil ?

[Ken Raeburn]

On Feb 22, 2011, at 07:00, Hans Aberg wrote:
[quoting others...]
>>> I noticed that that is possible - in fact, to make sure to get it right, I 
>>> removed all Guile headers in /usr/local/include/ and reinstalled guile-2.0.
>>> 
>>> The Guile 1.8 header libguile.h is in /usr/local/include/, but the one from 
>>> 2.0 is in /usr/local/include/guile/2.0/. Both directories are included when 
>>> compiling. So if the include order is wrong, or the from 2.0 is somehow 
>>> excluded, you may get the wrong one, and it may in fact compile.
>>> 
>>> Perhaps 2.0 should have some check that it gets the right header.

It wouldn't be that tough to do something like:

  #define scm_init_guile  scm_init_guile_v2_0 // encode version in symbol

or

  #define scm_init_guile scm_init_guile_with_version_check(0x0200) // one byte 
each major/minor vers

and tell people to use the macro.  Ugly, maybe, but not tough. :-)

>> 
>> Well~I modified the include path and it's done.
>> Thanks all!
> 
> If you use `guile-config compile` (and `guile-config link`) in your Makefile 
> it will come out right.

Unless you're also using some other "foo-config" script for the same object 
file (defining Guile wrappers for the Foo API?), and that one is installed in 
/usr/local where the old version of Guile is, you don't get the command-line 
order right for your specific installation quirks, etc.

I don't think there is a good answer to guarantee consistent versions; some 
additional technique to check for consistency doesn't seem like a horrible 
idea, though most packages I've worked with just seem to make do with the 
assumption that you'll figure out how to get this right if you're installing 
multiple versions.

Ken