* Summary of config.h variables and questions.
@ 2003-03-05 5:44 Rob Browning
2003-03-06 14:37 ` Marius Vollmer
2003-03-06 22:10 ` Kevin Ryde
0 siblings, 2 replies; 13+ messages in thread
From: Rob Browning @ 2003-03-05 5:44 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-05 5:44 Summary of config.h variables and questions Rob Browning
@ 2003-03-06 14:37 ` Marius Vollmer
2003-03-06 15:57 ` Rob Browning
2003-03-06 18:27 ` Rob Browning
2003-03-06 22:10 ` Kevin Ryde
1 sibling, 2 replies; 13+ messages in thread
From: Marius Vollmer @ 2003-03-06 14:37 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 14:37 ` Marius Vollmer
@ 2003-03-06 15:57 ` Rob Browning
2003-03-06 16:21 ` Marius Vollmer
` (2 more replies)
2003-03-06 18:27 ` Rob Browning
1 sibling, 3 replies; 13+ messages in thread
From: Rob Browning @ 2003-03-06 15:57 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 15:57 ` Rob Browning
@ 2003-03-06 16:21 ` Marius Vollmer
2003-03-06 16:32 ` Rob Browning
2003-03-06 16:34 ` Rob Browning
2003-03-06 16:49 ` Marius Vollmer
2003-03-06 17:26 ` Mikael Djurfeldt
2 siblings, 2 replies; 13+ messages in thread
From: Marius Vollmer @ 2003-03-06 16:21 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 16:21 ` Marius Vollmer
@ 2003-03-06 16:32 ` Rob Browning
2003-03-06 16:34 ` Rob Browning
1 sibling, 0 replies; 13+ messages in thread
From: Rob Browning @ 2003-03-06 16:32 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 16:21 ` Marius Vollmer
2003-03-06 16:32 ` Rob Browning
@ 2003-03-06 16:34 ` Rob Browning
2003-03-06 16:48 ` Marius Vollmer
1 sibling, 1 reply; 13+ messages in thread
From: Rob Browning @ 2003-03-06 16:34 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 15:57 ` Rob Browning
2003-03-06 16:21 ` Marius Vollmer
@ 2003-03-06 16:49 ` Marius Vollmer
2003-03-06 17:26 ` Mikael Djurfeldt
2 siblings, 0 replies; 13+ messages in thread
From: Marius Vollmer @ 2003-03-06 16:49 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 15:57 ` Rob Browning
2003-03-06 16:21 ` Marius Vollmer
2003-03-06 16:49 ` Marius Vollmer
@ 2003-03-06 17:26 ` Mikael Djurfeldt
2 siblings, 0 replies; 13+ messages in thread
From: Mikael Djurfeldt @ 2003-03-06 17:26 UTC (permalink / raw)
Cc: Marius Vollmer
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 14:37 ` Marius Vollmer
2003-03-06 15:57 ` Rob Browning
@ 2003-03-06 18:27 ` Rob Browning
2003-03-06 18:48 ` Marius Vollmer
1 sibling, 1 reply; 13+ messages in thread
From: Rob Browning @ 2003-03-06 18:27 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 18:27 ` Rob Browning
@ 2003-03-06 18:48 ` Marius Vollmer
0 siblings, 0 replies; 13+ messages in thread
From: Marius Vollmer @ 2003-03-06 18:48 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-05 5:44 Summary of config.h variables and questions Rob Browning
2003-03-06 14:37 ` Marius Vollmer
@ 2003-03-06 22:10 ` Kevin Ryde
2003-03-07 5:24 ` Rob Browning
1 sibling, 1 reply; 13+ messages in thread
From: Kevin Ryde @ 2003-03-06 22:10 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Summary of config.h variables and questions.
2003-03-06 22:10 ` Kevin Ryde
@ 2003-03-07 5:24 ` Rob Browning
0 siblings, 0 replies; 13+ messages in thread
From: Rob Browning @ 2003-03-07 5:24 UTC (permalink / raw)
Cc: guile-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-03-07 5:24 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-05 5:44 Summary of config.h variables and questions Rob Browning
2003-03-06 14:37 ` Marius Vollmer
2003-03-06 15:57 ` Rob Browning
2003-03-06 16:21 ` Marius Vollmer
2003-03-06 16:32 ` Rob Browning
2003-03-06 16:34 ` Rob Browning
2003-03-06 16:48 ` Marius Vollmer
2003-03-06 16:49 ` Marius Vollmer
2003-03-06 17:26 ` Mikael Djurfeldt
2003-03-06 18:27 ` Rob Browning
2003-03-06 18:48 ` Marius Vollmer
2003-03-06 22:10 ` Kevin Ryde
2003-03-07 5:24 ` Rob Browning
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).