[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.

From: Rob Browning
Subject: Re: Release Guile, now ;-) [was:] Re: GC rewrite, first version.
Date: Fri, 02 Aug 2002 09:50:12 -0500
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu)

address@hidden writes:

> I feel sorry seeing that my complaints cause such a lot of trouble.

No it's good.  If we're now #defining really generic things that break
compilation with other packages, then we really have to fix that.

> Hmm, i don't understand this. The offending header file is not
> generated by 'autoheader', it's processed by 'configure'. Instead of
> writing a custom c program that emits all needed #defines wouldn't
> it be sufficient to create by hand?

Actually I believe scmconfig.h is generated by autoheader.  See


And while I'd certainly be open to other options, the trivial C
program means we can use *exactly* the values that the auto* machinery
normally generates via config.h, and it'll automatically get the
dependencies right too.  When config.h changes, so will scmconfig.h.
Other solutions would be OK too, but this one seems nice and simple.

I thought about using configure to generate scmconfig.h from via embedded @FOO@ bits, but if you do that, then you
have to go through and add a whole lot more code to to
AC_DEFINE all the things you need, and you can't do #if* reasoning
based on the config.h HAVE_* defines to decide what to put in
scmconfig.h.  With the C program approach, you get this for "free".

> | AC_PREREQ(2.53)
> | 
> | AM_CONFIG_HEADER(libguile/scmconfig.h)
> | 
> |       [Define this if you want to debug the free list (helps w/ GC bugs).])
> | AC_DEFINE(GUILE ......
> | 

Sure we could do that, but what if we wanted to do things like:

  #ifdef HAVE_FOO && HAVE_BAR
    printf("#define ...");
    printf("typedef ...");
    printf("#define super fancy ...");

Of course, you can do this with the configure machinery, but I suspect
it's going to be more code, and not as straigtforward.  With the tiny
C program approach, you only have 2 files, the normal config.h you've
got to have anyhow and the C program, and the processing is just a
trivial rule, or to put it another way, when the info you
need's already going to be in a C header, it seemed most
straightforward to handle it via C.

> May i offer my help?

Sure, though we've got to figure out how much has to be done
immediately.  I'm suspecting we may be able to just back out
PACKAGE_NAME and a few of the other offenders and solve things more
correctly after 1.6.1.

Rob Browning
rlb,, and
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

reply via email to

[Prev in Thread] Current Thread [Next in Thread]