From: Rob Browning <rlb@defaultvalue.org>
Cc: Han-Wen Nienhuys <hanwen@cs.uu.nl>,
Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>,
guile-devel@gnu.org
Subject: Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.
Date: Thu, 01 Aug 2002 17:40:31 -0500 [thread overview]
Message-ID: <871y9i8aow.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <87wura8rzc.fsf@raven.i.defaultvalue.org> (Rob Browning's message of "Thu, 01 Aug 2002 11:27:03 -0500")
Rob Browning <rlb@defaultvalue.org> writes:
> 1.5.7 was ready to go. However since I'm waiting to upload anyway
> I'll go see how extensive the changes to fix it might be.
OK, after looking in to it, it seems like we probably need a number of
changes to get things "right". One of the main questions is how do
you generate a header that can be included in the install tree
containing info based on configure's results, but doesn't refer to any
of those results (at least not to the generic names). After poking
around a bit I propose the following solution:
* change our configure generated header to be config.h via
config.h.in as per the normal autoconf expectations and put it in
the normal place ./config.h.in. This will now be a completely
private header, not installed, and not included by anything but .c
files.
* change all *.c occurrences of #include ?libguile/scmconfig.h?" to
"#include <config.h>" except for the include in __scm.h. That one
will be left alone.
* add a rule to libguile/Makefile.am like this:
scmconfig.h: ${builddir}/scmconfig-generate
${builddir}/scmconfig-generate > scmconfig.h.tmp
mv scmconfig.h.tmp scmconfig.h
* write libguile/scmconfig-generate.c to use the values in
<config.h> to generate a config.h independent header like this:
#include <config.h>
#include <stdio.h>
int
main (int argc, char *argv[])
{
printf(
"/* libguile/scmconfig.h -*-c-*-
This file contains bits that were determined automatically, but
should be included in the guile public header install
This file is generated automatically from
libguile/scmconfig-generate. Please make changes there.
*/\n\n");
#ifdef HAVE_LONG_LONGS
printf("#define SCM_HAVE_LONG_LONGS");
#endif
/* etc. */
return 0;
}
This allows us to autogenerate the file from the contents of
config.h without having to do anything too fancy with
sed/config.status, etc.
* go through and add items to scmconfig-generate.c as needed, but
leave as much as possible in <config.h> -- where it'll be private.
For example, I'm guessing that most of the HAVE_FOO macros won't
be public, and the ones that must be public (i.e. in scmconfig.h)
should be renamed to SCM_HAVE_FOO, or similar.
But this looks like a non-trivial amount of work. I've already done
all the steps but the last in a test tree, but that's the big one.
So the question is, does this have to be done before 1.6.1?
Also while poking around I noticed that there are at least several
#defines in __scm.h that appear to serve no purpose -- they're not
referred to anywhere else. I'm wondering if these can be dropped.
For example, TICKS isn't used anywhere, and it looks like ENGNOT could
be moved to numbers.c without problems.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-08-01 22:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-27 22:54 GC rewrite, first version Han-Wen
2002-07-28 16:40 ` Rob Browning
2002-07-29 20:11 ` Dirk Herrmann
2002-07-29 21:04 ` Rob Browning
2002-07-29 22:05 ` Han-Wen
2002-07-31 17:03 ` Dirk Herrmann
2002-07-31 18:02 ` Han-Wen Nienhuys
2002-07-31 21:15 ` Rob Browning
2002-08-01 9:20 ` Release Guile, now ;-) [was:] " rm
2002-08-01 16:27 ` Rob Browning
2002-08-01 16:44 ` rm
2002-08-01 18:37 ` Sergey Poznyakoff
2002-08-01 22:21 ` Rob Browning
2002-08-02 6:09 ` Sergey Poznyakoff
2002-08-02 14:36 ` Rob Browning
2002-08-02 17:29 ` Sergey Poznyakoff
2002-08-02 18:10 ` Bruce Korb
2002-08-02 19:50 ` Rob Browning
2002-08-03 7:13 ` Sergey Poznyakoff
2002-08-04 20:43 ` Bruce Korb
2002-08-04 20:57 ` Sergey Poznyakoff
2002-08-01 22:40 ` Rob Browning [this message]
2002-08-02 9:35 ` rm
2002-08-02 11:59 ` rm
2002-08-02 15:00 ` Rob Browning
2002-08-02 14:50 ` Rob Browning
2002-08-01 9:59 ` Han-Wen Nienhuys
2002-08-01 8:46 ` Marius Vollmer
2002-07-31 18:46 ` Neil Jerram
2002-08-01 9:58 ` Han-Wen Nienhuys
2002-07-28 16:51 ` Michael Livshin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871y9i8aow.fsf@raven.i.defaultvalue.org \
--to=rlb@defaultvalue.org \
--cc=dirk@sallust.ida.ing.tu-bs.de \
--cc=guile-devel@gnu.org \
--cc=hanwen@cs.uu.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).