l...@gnu.org (Ludovic Courtès) writes:
> Hi Neil,
Hi again!
> Neil Jerram <n...@ossau.uklinux.net> 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
