From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: A few config.h and scmconfig.h overhaul related issues. Date: Mon, 17 Mar 2003 14:46:55 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87wuixpvpc.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047934128 22830 80.91.224.249 (17 Mar 2003 20:48:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 17 Mar 2003 20:48:48 +0000 (UTC) Cc: marius.vollmer@uni-dortmund.de Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Mar 17 21:48:46 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18v1XJ-0005vv-00 for ; Mon, 17 Mar 2003 21:48:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18v1Wr-0001P8-03 for guile-devel@m.gmane.org; Mon, 17 Mar 2003 15:48:17 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18v1WZ-0001N5-00 for guile-devel@gnu.org; Mon, 17 Mar 2003 15:47:59 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18v1Vv-0001B6-00 for guile-devel@gnu.org; Mon, 17 Mar 2003 15:47:22 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18v1Va-0000xr-00 for guile-devel@gnu.org; Mon, 17 Mar 2003 15:46:58 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 6BD2A13ED6; Mon, 17 Mar 2003 14:46:56 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 087E6E3676; Mon, 17 Mar 2003 14:46:56 -0600 (CST) Original-To: guile-devel@gnu.org User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2084 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2084 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 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