guile-devel
[Top][All Lists]
Advanced

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

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'


From: Ludovic Courtès
Subject: Re: Guile 1.8 success on `i386-apple-darwin9.6.0'
Date: Fri, 27 Mar 2009 09:58:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux)

Good morning!

Neil Jerram <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:

>> Maybe we could detect in `configure' whether we are
>> cross-compiling and conditionalize build of
>> `stack-limit-calibration.scm' on that?
>
> No, that sounds too tricky.  I'm persuaded now that your change is
> good.

Alright.

> Just one nit: I think there's now only 1 piece of Automake magic being
> relied on, so you could update that text (in Makefile.am) and remove
> the "2. ".

Right, I did this:

  
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=0fe95f9c4ce063781e79a15bc123c57c33ef9755

>> There are internal declarations in essentially every `.h' (88 files).
>> Presumably we'd have to put them in a single `.h' rather than creating
>> 88 new headers.  The drawback is that declarations would thus live in a
>> header whose name does not match the name of files where the definitions
>> occur.
>
> I agree that that wouldn't be nice.  But how about:
>
> - preserving all the installed header names as they are now (even
>   though we could maybe make a case for only preserving "libguile.h")
>
> - splitting individual headers one-by-one, only when we have a need to
>   do so:
>
>   - public header name xyz.h (unchanged)
>
>   - private header name _xyz.h

So IIUC you're advocating the creation of 88 new header files, right?
To me it looks like it would way too much overhead, especially since
each private header would contain few declarations.

>   - the private header #includes the public header
>
>   - in libguile/*.c, globally replace "xyz.h" with "_xyz.h". 
>
> That feels nice enough to me.  What do you think?

I think I'd prefer the single-private-header option, but I'm not 100%
convinced either.

Actually there's yet another option: enclose internal declarations in
"#ifdef LIBGUILE_IN_LIBGUILE" or similar, which we only define when
compiling Guile itself.  This is what Glibc does with, e.g.,
`__LIBC_INTERNAL_MATH_INLINES' and what GMP does with
`__GMP_WITHIN_GMP'.  I think I like it better.

Thanks,
Ludo'.





reply via email to

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