Re: Summary of config.h variables and questions.

[Marius Vollmer <mvo@zagadka.de>]

Rob Browning <rlb@defaultvalue.org> writes:

> I've also been through *all* of our defines in config.h and evaluated
> each one to figure out what should be done with it.

Excellent work!  Thank a lot for doing this, Rob!

Since this is a major change, we should not be doing it in the 1.6
series unless there is a real and specific problem with them (as with
PACKAGE).  For 1.7, we can make more sweeping changes to offer better
alternatives (see below).

> The second category is comprised of those symbols that we were using
> in our public headers, but whose names are probably not suitable for
> the global namespace.  These I haven't done anything about because I
> wanted to see how everyone else thought we should handle them.  One
> option would be to add an SCM_ prefix to all of their names and
> carry on.  Of course doing so would break any client code that was
> using these symbols, but this may be a case where such a change is
> warranted, since we probably shouldn't have used these names
> publically in the first place.

Agreed.  I regard it as a bug that we export most of these symbols,
not as a feature.  However, some of these macros are specific to Guile
(such as USE_THREADS) and we should keep them around as a deprecated
feature for a few years.

> Note that "const" and "inline" above are normally #defined by
> configure in config.h to be something suitable for the given platform
> when possible, or #undef'ed otherwise.  If we have been (or want to)
> take advantage of this facility in our public headers, we probably
> need to use SCM_INLINE and SCM_CONST or similar...

Yes. "inline" and "const" are not specific to Guile and people should
not expect Guile to provide definitions for them.

> So presuming we don't mind removing any of these symbols from our
> public API, we should be finished with them:

We should keep these, since they have a proper name already:

>   GUILE_DEBUG_MALLOC

We should deprecate-and-keep these:

>   DYNAMIC_LINKING
>   GUILE_ISELECT
>   READER_EXTENSIONS
>   STACK_DIRECTION
>   USE_THREADS

Alternatives are

    DYNAMIC_LINKING
    - assume that DYNAMIC_LINKING is always present.

    GUILE_ISELECT
    - assume that scm_internal_select is always present.

    READER_EXTENSIONS
    - assume that it is always present.

    STACK_DIRECTION
    - there should be no need to know about the stack direction for
      ordinary programs.  Do not use.

    USE_THREADS
    - assume that the thread API is always present.


Ok?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel