A few config.h and scmconfig.h overhaul related issues.

* A few config.h and scmconfig.h overhaul related issues.
@ 2003-03-17 20:46 Rob Browning
  2003-03-18 18:13 ` Rob Browning
  0 siblings, 1 reply; 2+ messages in thread
From: Rob Browning @ 2003-03-17 20:46 UTC (permalink / raw)
  Cc: marius.vollmer

After switching (back) to the "gen-scmconfig > scmconfig.h" approach
(using a tiny C program), things have gone fairly smoothly.  I have a
tree which (I believe) no longer publically defines any config.h
symbols, other than the few deprecated bits Marius mentioned, that are
not prefixed with SCM_ or GUILE_.

However, there are a few remaining issues I wanted to discuss:

  - Marius suggested deprecate-and-keep DYNAMIC_LINKING, but what
    about --with-modules use (see configure.in)?

  - What was the final word on GUILE_DEBUG_MALLOC?  Should it be
    public or private?  It's never referenced in a public header, but
    do we know our clients don't need it?

  - There are a number of defines in __scm.h that I overlooked before
    when I was only looking at config.h symbols.  What, if anything,
    do we want to do about these?

      BIGNUMS (used in numbers.h, but do we ever *not* define it?)
      TICKS (doesn't appear to be used - remove?)
      ENGNOT (never used publically -- move to _scm.h?)
      CCLO (never used publically -- move to _scm.h?)
      SICP (never used publically -- move to _scm.h?)
      STACK_CHECKING (can we replace with existing SCM_STACK_CHECKING_P?)
      NO_CEVAL_STACK_CHECKING (doesn't appear to be used -- remove?)

  - the only public use of (SCM_)HAVE_STDC_HEADERS is in numbers.h, as
    is the only public use of HAVE_FLOATINGPOINT_H, HAVE_IEEEFP_H, and
    HAVE_NAN_H.  I can just change these to SCM_HAVE_NAN_H, etc. if
    needed, but I wanted to make sure no one else had an alternative.
    I was able to remove the public use of many of the private
    config.h symbols by computing #defines in gen-scmconfig, but I'm
    pretty sure that won't work in this case -- especially since we
    probably don't want to have scmconfig.h including nan.h, whenever
    available, etc.

  - I'm not sure we care, but there are a number of #defines that are
    never used like SCM_SINGLES.

  - should we be using #include <libguile/__scm.h> in our public
    headers rather than #include "libguile/__scm.h"?

  - at the moment we don't always include config.h and scmconfig.h (or
    their parallels _scm.h and __scm.h) *before* any other includes.
    Sometimes we include various system headers or similar and then
    #include "libguile/__scm.h" or similar.  I suspect we should
    probably change this.  The main reason is that our public and
    private config headers may define things that affect the system
    header includes, things like _GNU_SOURCE that need to be defined
    first.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

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

^ permalink raw reply	[flat|nested] 2+ messages in thread