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

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> Hi Neil,

Hi again!

> Neil Jerram <address@hidden> writes:
>
>> I'm not sure about moving stack-limit-calibration.scm from TESTS to
>> BUILT_SOURCES.  The point of putting it in TESTS was to help with
>> cross-compiling.  When cross-compiling, my understanding is that
>> `make' should be run in a build host environment, and `make check' in
>> a target host environment.  stack-limit-calibration.scm should be
>> calculated in the target host environment, so it makes better sense to
>> do it as part of `make check' than as part of `make'.
>
> Hmm, right.  OTOH, my impression was that tools like Scratchbox had
> taken the world over, meaning that cross-compilation usually takes place
> as "native" compilation in an emulated target environment.

Ah, OK.  If you feel fairly confident about that, I'm happy to defer
to you on this; I don't really understand cross-compiling that well,
but I think what you say is consistent with the scratchbox builds that
I've done.

> The thing is that `stack-limit-calibration.scm' is really needed in
> cases like this.

That is pretty compelling!

> 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.

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. ".

>>>     (The calibrated stack limit on this machine is 45771, i.e., slightly
>>>      more than on GNU/Linux.)
>>
>> Isn't that 2.5 times more?  (i.e. not "slightly" :-))  I believe the
>> GNU/Linux limit is 20000.
>
> It's been 40000 since commit 32c8ae20.

Ah, OK, didn't notice that; thanks.

>> Moving internal things into non-installed headers feels like the best
>> thing to me.
>
> 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

  - 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?

Regards,
        Neil