Hi Neil, 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. The thing is that `stack-limit-calibration.scm' is really needed in cases like this. Maybe we could detect in `configure' whether we are cross-compiling and conditionalize build of `stack-limit-calibration.scm' on that? >> (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. > 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. Thanks, Ludo'.
