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

[Bruce Korb]

On 02/24/11 08:35, Ken Raeburn wrote:
> 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
....
> If the library ABI is tweaked to code the version into a symbol
> name, this test could become a simple compile-and-link test.

Exactly.

> Of course, that approach has other issues, like getting
> backwards-compatible library upgrades to work without recompiling
> applications.

The .so simply includes the versioned interfaces it supports.
They are simply not declared in the current interface.

> I vaguely remember reading an argument years back for including
> individual headers by pathname, rather than building up

The problem is naming conflicts.  The standard way to avoid
this is by including some directory information in the include
name.  e.g.  <libguile/guile.h> instead of <libguile.h>.
If someone really wants to ensure 2.0 vs. 1.8, then you can
put versioned subdirectories under /usr/include/libguile and
add a symlink farm to redirect requests to the current version.
But we're here now and I am saying that a mechanism needs to
be put into place whereby there is a hard build time failure
when /usr/include/libguile.h gets pulled in ahead of the
versioned header.  How precisely that is done is an exercise
for the Guile maintainers.  I'd make suggestions, but I have
to presume that you-all are inventive people, too.

>> * 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

No, it is one of those "commonly known" things that isn't
particularly commonly known.  It would be a jog to people's
memories in an attempt to help make it actually commonly known.
(: Suggested here mainly because Guile introduces such a conflict. :)

>> * 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.

If you promise to never, ever make any change that makes any
client adjust code in any way, then the micro version can be
left off.  OTOH, adding in a few more bits just in case you
have to is pretty cheap ....

Besides, people are already doing it, this would just put the
practice into the Guile header instead of my config.h header.