I know how to build Racket from source and then use the copy of Chez Scheme built as part of the process, as discussed in Running chez after building Racket?. My case (as part of working on the Guix packaging of Racket) is somewhat different: essentially, having bootstrapped bootfiles with Racket 3M and build Chez Scheme all the way through make install, I now want to build Racket CS from a fresh copy of the https://github.com/racket/racket sources, reusing as much of the Chez Scheme build I've already done as reasonable. (I can rely on Guix to make sure the versions exactly the same, which could cause many problems otherwise.)
I see that racket/src/cs/c/configure.ac provides an --enable-scheme option, which seems like what I need, but I'm not sure what it should point to. It seems to set CS_HOST_WORKAREA_PREFIX for racket/src/cs/c/Makefile.in, but that is concatenated with SCHEME_WORKAREA = ChezScheme to form SCHEME_HOST_WORKAREA = $(CS_HOST_WORKAREA_PREFIX)$(SCHEME_WORKAREA), which I don't really follow.
I've also seen that the ta6le (for example) directory from generating bootfiles includes equates.h, gc-ocd.inc, gc-oce.inc, gc-par.inc, and heapcheck.inc, which are not installed by make install. On the other hand (perhaps obviously?), the installed files include libkernel.a and main.o, which are not built with the bootfiles. (Both include scheme.h. And similar differences apply to upstream Chez Scheme's bootfiles vs. installed files.)
Can --enable-scheme point to some part of an installed Chez Scheme? Or, perhaps, do I need to save some part of the workspace from building Chez Scheme?
Edit: I don't think I understood the question the first time around. So, here's a revised answer that I think matches the question better:
The existing --enable-scheme option is really for cross compilation. The Racket configure and build scripts are not really set up to use a separate Chez Scheme in the way you have in mind.
It would make sense to add an option to generate boot files via an existing Chez Scheme installation instead of going through a pb build. At the level of the cs/c/Makefile.in, the implementation would probably involve creating variant of the scheme target that uses an installed scheme executable instead of scheme-via-pb to get the Chez Scheme scripts to create boot files. At the level of the Chez Scheme scripts, there would need to be a new configure and make mode to use an existing scheme to create boot files; in part, that's a matter of not setting SCHEMEHEAPDIRS before running scheme.
Original answer (to the wrong question):
The latter: it should point to the <build>/cs/c directory of your earlier build, which contains a ChezScheme directory containing the earlier workarea. The result of make install (as any level) doesn't include the pieces that --enable-scheme is looking for.
It would be possible to have a better variant of --enable-scheme that sets up things differently and can use an installed Chez Scheme. Or, probably better, when --enable-racket is provided alone, that could trigger a mode that accessed the Chez Scheme inside Racket to drive a cross build (which is a trick that raco cross uses). I'm not sure how easy it would be to adjust the configure scripts and makefile, though.
I think it's going to be practical to make --enable-scheme=<executable> work , so I'm trying to change the build scripts to support that, while also still supporting the old use of --enable-scheme=<dir>.
Supplying --enable-scheme=... is also an option if you alerady
have the same version of Chez Scheme built on the current platform.
Another build will be created, anyway, but more quickly than
without Chez Scheme.
I've already been avoiding a pb step: using Racket 3M, I bootstrap the native (e.g. ta6le) bootfiles directly and save them (as an intermediate Guix package). Before building (1) Racket's variant of Chez Scheme and (2) Racket CS, each of which starts with a fresh set of sources, I unpack the bootstrapped bootfiles into racket/src/ChezScheme/boot.
It sounds like that might be as much sharing as is reasonable to do anyway. But maybe it still makes sense to switch to --enable-scheme=scheme, if that's more similar to what will be needed when I deal with cross-compilation, eventually? I'm not sure.