Summary of config.h variables and questions.

Summary of config.h variables and questions.

[Rob Browning]

It looks like Andreas suggested approach of using AC_CONFIG_COMMANDS
to handle our public header will work.  I've made the corresponding
adjustments to our tree (but haven't committed yet), and have arranged
it so that config.h is still automatically generated by
autoheader/configure and libguile/scmconfig.h is now our public
header.

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.  However, I
haven't actually been able to compile yet because there are some
outstanding issues that still need to be resolved.

The config.h symbols fall into three categories.  The first (and
smallest) are the symbols that were being used in some of our .h files
(i.e. were definitely public), *and* had suitable names for public
use.  For these, I just arranged for configure to put them into
libguile/scmconfig.h unmolested:

  GUILE_DEBUG
  GUILE_DEBUG_FREELIST
  SCM_ENABLE_DEPRECATED
  SCM_ENABLE_ELISP
  SCM_STACK_GROWS_UP (how does this relate to STACK_DIRECTION?)

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.

Another alternative for some of the symbols might be to rewrite the
code in a way that eliminates the need for a given symbol to be in our
public headers, though I suspect the number of cases where we can do
that easily is small (note that if it helps, we can do some
computation in configure.in before adding the #defines to scmconfig.h
-- precomputing #define contents, etc.).  Here are the symbols that we
have to decide about:

  DEBUG_EXTENSIONS
  HAVE_ARRAYS
  HAVE_FLOATINGPOINT_H
  HAVE_IEEEFP_H
  HAVE_INLINE
  HAVE_INTTYPES_H
  HAVE_LIMITS_H
  HAVE_NAN_H
  HAVE_STDINT_H
  HAVE_STRUCT_TIMESPEC
  HAVE_SYS_STDTYPES_H
  HAVE_SYS_TIME_H
  HAVE_SYS_TYPES_H
  HAVE_TIME_H
  HAVE_WINSOCK
  SIZEOF_LONG
  SIZEOF_LONG_LONG
  SIZEOF_PTRDIFF_T
  SIZEOF_UINTPTR_T
  STDC_HEADERS
  TIME_WITH_SYS_TIME
  USE_DLL_IMPORT
  USE_NULL_THREADS
  USE_PTHREAD_THREADS
  _POSIX_
  _THREAD_SAFE
  const
  inline

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

The third category contains those symbols which weren't being used
publically.  They were only being used by .c files or non-public
headers, or weren't being used at all.  For these, I just made sure
that the relevant files include config.h properly:

  #if HAVE_CONFIG_H
  #  include <config.h>
  #endif

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

  CRAY_STACKSEG_END
  C_ALLOCA
  DYNAMIC_LINKING
  GETGROUPS_T
  GUILE_DEBUG_MALLOC
  GUILE_ISELECT
  HAVE_ALLOCA
  HAVE_ALLOCA_H
  HAVE_ARGZ_APPEND
  HAVE_ARGZ_CREATE_SEP
  HAVE_ARGZ_H
  HAVE_ARGZ_INSERT
  HAVE_ARGZ_NEXT
  HAVE_ARGZ_STRINGIFY
  HAVE_ASSERT_H
  HAVE_ATEXIT
  HAVE_BCOPY
  HAVE_CHOWN
  HAVE_CHROOT
  HAVE_CONNECT
  HAVE_COPYSIGN
  HAVE_CRYPT_H
  HAVE_CTERMID
  HAVE_CTYPE_H
  HAVE_CUSERID
  HAVE_DIRECT_H
  HAVE_DIRENT_H
  HAVE_DLD
  HAVE_DLD_H
  HAVE_DLERROR
  HAVE_DLFCN_H
  HAVE_DL_H
  HAVE_ENDHOSTENT
  HAVE_ENDNETENT
  HAVE_ENDPROTOENT
  HAVE_ENDSERVENT
  HAVE_ERRNO_H
  HAVE_ERROR_T
  HAVE_FCHOWN
  HAVE_FCNTL
  HAVE_FINITE
  HAVE_FLOCK
  HAVE_FORK
  HAVE_FTIME
  HAVE_GETCWD
  HAVE_GETEUID
  HAVE_GETGRENT
  HAVE_GETGROUPS
  HAVE_GETHOSTBYNAME
  HAVE_GETITIMER
  HAVE_GETLOGIN
  HAVE_GETNETBYADDR
  HAVE_GETNETBYNAME
  HAVE_GETNETENT
  HAVE_GETPASS
  HAVE_GETPGRP
  HAVE_GETPPID
  HAVE_GETPRIORITY
  HAVE_GETPROTOINT
  HAVE_GETPWENT
  HAVE_GETSERVENT
  HAVE_GETTIMEOFDAY
  HAVE_GRP_H
  HAVE_HSTRERROR
  HAVE_H_ERRNO
  HAVE_INDEX
  HAVE_INET_ATON
  HAVE_INET_LNAOF
  HAVE_INET_NETOF
  HAVE_INET_NTOP
  HAVE_INET_PTON
  HAVE_IO_H
  HAVE_IPV6
  HAVE_ISINF
  HAVE_ISNAN
  HAVE_KILL
  HAVE_LIBCRYPT
  HAVE_LIBC_H
  HAVE_LIBC_STACK_END
  HAVE_LIBDL
  HAVE_LIBGMP
  HAVE_LIBM
  HAVE_LIBNSL
  HAVE_LIBREGEX
  HAVE_LIBRX
  HAVE_LIBSOCKET
  HAVE_LIBWS2_32
  HAVE_LINK
  HAVE_LSTAT
  HAVE_MALLOC_H
  HAVE_MEMCPY
  HAVE_MEMMOVE
  HAVE_MEMORY_H
  HAVE_MKDIR
  HAVE_MKNOD
  HAVE_MKSTEMP
  HAVE_NDIR_H
  HAVE_NETWORKING
  HAVE_NICE
  HAVE_ON_EXIT
  HAVE_PAUSE
  HAVE_POSIX
  HAVE_PRELOADED_SYMBOLS
  HAVE_PUTENV
  HAVE_PWD_H
  HAVE_READLINK
  HAVE_REGCOMP
  HAVE_REGEX_H
  HAVE_RENAME
  HAVE_RESTARTABLE_SYSCALLS
  HAVE_RINDEX
  HAVE_SELECT
  HAVE_SETEGID
  HAVE_SETEUID
  HAVE_SETHOSTENT
  HAVE_SETHOSTNAME
  HAVE_SETITIMER
  HAVE_SETLOCALE
  HAVE_SETNETENT
  HAVE_SETPGID
  HAVE_SETPRIORITY
  HAVE_SETPROTOENT
  HAVE_SETPWENT
  HAVE_SETSERVENT
  HAVE_SETSID
  HAVE_SHL_LOAD
  HAVE_SIGACTION
  HAVE_SIGINTERRUPT
  HAVE_SIN
  HAVE_SOCKETPAIR
  HAVE_STDIO_H
  HAVE_STDLIB_H
  HAVE_STRCHR
  HAVE_STRCMP
  HAVE_STRDUP
  HAVE_STRERROR
  HAVE_STRFTIME
  HAVE_STRINGS_H
  HAVE_STRING_H
  HAVE_STRPTIME
  HAVE_STRRCHR
  HAVE_STRUCT_LINGER
  HAVE_STRUCT_STAT_ST_BLKSIZE
  HAVE_STRUCT_STAT_ST_BLOCKS
  HAVE_STRUCT_STAT_ST_RDEV
  HAVE_STRUCT_TM_TM_ZONE
  HAVE_ST_BLOCKS
  HAVE_SYMLINK
  HAVE_SYNC
  HAVE_SYSTEM
  HAVE_SYS_DIR_H
  HAVE_SYS_DL_H
  HAVE_SYS_FILE_H
  HAVE_SYS_IOCTL_H
  HAVE_SYS_NDIR_H
  HAVE_SYS_RESOURCE_H
  HAVE_SYS_SELECT_H
  HAVE_SYS_STAT_H
  HAVE_SYS_STDTYPES_H
  HAVE_SYS_TIMEB_H
  HAVE_SYS_TIMES_H
  HAVE_SYS_UTIME_H
  HAVE_SYS_UTSNAME_H
  HAVE_SYS_WAIT_H
  HAVE_S_ISLNK
  HAVE_TCGETPGRP
  HAVE_TCSETPGRP
  HAVE_TIMES
  HAVE_TM_ZONE
  HAVE_TTYNAME
  HAVE_TZNAME
  HAVE_TZSET
  HAVE_UINT32_T
  HAVE_UNAME
  HAVE_UNISTD_H
  HAVE_UNIX_DOMAIN_SOCKETS
  HAVE_USLEEP
  HAVE_UTIME_H
  HAVE_WAITPID
  LIBC_H_WITH_UNISTD_H
  LOCALTIME_CACHE
  LTDL_DLOPEN_DEPLIBS
  LTDL_OBJDIR
  LTDL_SHLIBPATH_VAR
  LTDL_SHLIB_EXT
  LTDL_SYSSEARCHPATH
  MISSING_SLEEP_DECL
  MISSING_STRPTIME_DECL
  MISSING_USLEEP_DECL
  NEED_USCORE
  PACKAGE_BUGREPORT
  PACKAGE_NAME
  PACKAGE_STRING
  PACKAGE_TARNAME
  PACKAGE_VERSION
  READER_EXTENSIONS
  SCM_MUTEXATTR_SETTYPE_DECLARED (should this be SCM_I_?)
  SCM_MUTEX_FAST
  SCM_MUTEX_RECURSIVE
  SCM_SINGLES
  SCM_WARN_DEPRECATED_DEFAULT
  SIZEOF_INT
  SIZEOF_SHORT
  SIZEOF_SIZE_T
  SIZEOF_UNSIGNED_INT
  SIZEOF_UNSIGNED_LONG
  SIZEOF_UNSIGNED_LONG_LONG
  SIZEOF_UNSIGNED_SHORT
  SIZEOF_VOID_P
  STACK_DIRECTION
  TM_IN_SYS_TIME
  USE_THREADS
  USLEEP_RETURNS_VOID
  UTIMBUF_NEEDS_POSIX
  WORDS_BIGENDIAN
  _ALL_SOURCE
  _MINIX
  _POSIX_SOURCE
  error_t
  gid_t
  mode_t
  uid_t

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

Re: Summary of config.h variables and questions.

[Marius Vollmer]

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

Re: Summary of config.h variables and questions.

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

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

Definitely.  I'm only working on the 1.7 tree right now.

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

Right.  The main question I had about this one was whether it needed
to be public -- it looks like it isn't used in any of our public
headers, but it was visible via scmconfig.h

> We should deprecate-and-keep these:
>
>>   DYNAMIC_LINKING
>>   GUILE_ISELECT
>>   READER_EXTENSIONS
>>   STACK_DIRECTION
>>   USE_THREADS
>
> Alternatives are

What do you mean by "Alternatives", an alternative to
"deprecate-and-keep"?

Thanks

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

Re: Summary of config.h variables and questions.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> > Alternatives are
> 
> What do you mean by "Alternatives", an alternative to
> "deprecate-and-keep"?

No, when we deprecate something, we need an alternative to replace the
deprecated thing with.


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

Re: Summary of config.h variables and questions.

[Rob Browning]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> No, when we deprecate something, we need an alternative to replace the
> deprecated thing with.

Ahh, ok, so you meant that text would go in the "deprecated features"
documentation.

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

Re: Summary of config.h variables and questions.

[Rob Browning]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> No, when we deprecate something, we need an alternative to replace the
> deprecated thing with.

OK.  So I'll go ahead with the changes.  Once I straighten them out,
I'll commit to HEAD.

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

Re: Summary of config.h variables and questions.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> OK.  So I'll go ahead with the changes.  Once I straighten them out,
> I'll commit to HEAD.

Right.  Thanks a lot!

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

Re: Summary of config.h variables and questions.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> > We should keep these, since they have a proper name already:
> >
> >>   GUILE_DEBUG_MALLOC
> 
> Right.  The main question I had about this one was whether it needed
> to be public -- it looks like it isn't used in any of our public
> headers, but it was visible via scmconfig.h

I don't think it _needs_ to be public, but it is right now and it does
no harm.  So changing it has a (slightly) higher cost than keeping it
the way it is.

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

Re: Summary of config.h variables and questions.

[Mikael Djurfeldt]

Rob Browning <rlb@defaultvalue.org> writes:

>>>   GUILE_DEBUG_MALLOC
>
> Right.  The main question I had about this one was whether it needed
> to be public -- it looks like it isn't used in any of our public
> headers, but it was visible via scmconfig.h

It doesn't need to be visible publicly.  It is only used to compile in
some extra code in order to provide the memory debugging function
`malloc-stats'.

Probably it should be renamed according to the new style for debug
options (SCM_DEBUG_XXX).


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

Re: Summary of config.h variables and questions.

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

>>   DYNAMIC_LINKING

So how should --with-modules (and its attendant settings) be handled?

>>   STACK_DIRECTION

For this one, we're not defining it, so I'm guessing we shouldn't make
it public.  This is defined by the built-in autoconf alloca function
check.  People should be using (and probably were unless they just
looked around in our scmconfig.h file) SCM_STACK_GROWS_UP.  So I'd be
tempted to just leave this one private.

Oh, and just so I'm clear, what was your opinion about all the other
"undecided" symbols?  If you didn't mention them, then does that mean
you think they should be published, prefixed with SCM_ or perhaps
something else?  They all have to be public in some way since we use
them in our headers.

I'll guess I'll change const to SCM_CONST and inline to SCM_INLINE or
similar along with all our public uses[1], but what about the rest
(i.e. DEBUG_EXTENSIONS -- which used to be public, but was deprecated,
HAVE_ARRAYS, etc.)?

[1] or do we just want to insist we have const?

Also, with the approach we're using, generating the public header from
configure.in, I can only make things public where we can get access to
the configure determined value.  So far that's been everything we've
cared about, but I thought I'd mention the limitation.  If something
is only AC_DEFINEd by configure.in macros that we don't have access
to, and there was no provision to add our own configure.in IF-TRUE,
IF-FALSE code, then we might be stuck.

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

Re: Summary of config.h variables and questions.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.de> writes:
> 
> >>   DYNAMIC_LINKING
> 
> So how should --with-modules (and its attendant settings) be handled?

What does --with-modules do.  I know we have it, but I don't know what
it is.  Is it some libtool thing?

> >>   STACK_DIRECTION
> 
> For this one, we're not defining it, so I'm guessing we shouldn't make
> it public.  This is defined by the built-in autoconf alloca function
> check.

I see.  In that case I agree that we can remove it from the public
API.

> Oh, and just so I'm clear, what was your opinion about all the other
> "undecided" symbols?

They can be removed from the public API.  Sorry for not being clear.

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

Re: Summary of config.h variables and questions.

[Kevin Ryde]

Rob Browning <rlb@defaultvalue.org> writes:
>
> 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...

It's worth bearing in mind that const and inline are aspects of the
compiler, so ideally they'd be determined based on #ifdefs, allowing
an application to be built with a different compiler than guile was
compiled with.

I'd suspect const doesn't need to be tested these days, especially not
if K&R isn't supported by the rest of the header file stuff.

For inline, maybe just testing for gcc or C++ would be enough, and let
anyone using a vendor compiler put their hand up.  If inline is only
used for optimizations then there'd be no great loss if a few non-free
compilers missed out on it.


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

Re: Summary of config.h variables and questions.

[Rob Browning]

Kevin Ryde <user42@zip.com.au> writes:

> It's worth bearing in mind that const and inline are aspects of the
> compiler, so ideally they'd be determined based on #ifdefs, allowing
> an application to be built with a different compiler than guile was
> compiled with.

The way I've currently reworked it is so that we define SCM_C_INLINE
(we can use another name if people don't like that one) to be whatever
autoconf figures out for the "correct" inline term, if it finds one at
all.  AC_C_INLINE tests for inline, __inline, and _inline.  Apparently
this covers some range of compilers...

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