On Wed, Oct 24, 2018 at 7:12 PM Taylor R Campbell <
address@hidden> wrote:
> Date: Tue, 23 Oct 2018 14:47:07 -0700
> From: Chris Hanson <address@hidden>
>
> I just merged my makefile-refactor branch into master.
Just tried ./Setup.sh && ./configure in a clean tree, and
(a) various parts of the build tried to use the variable
microcode-id/operating-system-suffix, which doesn't exist in 9.2, but
(b) they didn't fail noisily, so instead error messages about the
undefined variable got embedded in makefiles, which leads to some
mighty confusing compounded error messages down the line, and
(c) for some reason --batch-mode doesn't suppress --no-init-file, so
garbage about `Loading "/home/riastradh/.scheme.init"... done'
also got embedded in all the makefiles.
Can you avoid using what doesn't exist in 9.2 in the build, and pass
--no-init-file?
I'm pretty sure the only thing that uses microcode-id/operating-system-suffix is the configure scripts in the plugins, which you should not try to compile using 9.2 (pass the --disable-default-plugins flag to configure).
I'll modify everything to add --no-init-file.
> The changes are pretty extensive:
>
> - The "toolchain" compilation is gone, as is the bulk of the contents of
> host-adapter. Compilation now makes a single pass through everything. In
> general, cross compilation is now achieved by a two-stage compilation with
> separate build directories.
I'm a little disappointed about this part. One of the lessons NetBSD
taught me -- that redoing these makefiles a few years ago reinforced
for me -- is that for an operating system and toolchain (like NetBSD
or like, in some sense as a platform, MIT Scheme),
1. every build should be a cross-build by default,
2. the toolchain -- whether for native- or cross-compilation -- should
always function as a normal application that you can build with a
prior version of the system, not as something that has an
incestuous relationship with the host or target runtime system, and
3. a clean toolchain is the first thing you should build.
I don't disagree with these principals. What exists now follows (2) and (3) except that they are now done in separate stages, which simplifies the build machinery. I was very unhappy with the building of a toolchain that consisted of a bastard combination of the older runtime and the newer compiler -- that no longer happens with the new arrangement. Instead there's a toolchain built with the old system that is a compiled from the new system's sources. Which, as I said, greatly simplified the host-adapter, which now mostly consists of syntax definitions that aren't available in 9.2; previously there was a slew of renames and adapters needed to get the new compiler to run in the old runtime.
I don't see the advantage of trying to combine the entire build into something that folds the toolchain stage into the primary build. Yes, it would be more automatic, but that can be achieved using a shell script, much like we do for run-three-stages.
This way, the output of a build is the output of an up-to-date
toolchain applied to up-to-date runtime sources, the cross-compilation
paths don't bitrot, and manual multi-stage builds are practically
never necessary.
This also creates an up-to-date toolchain, but doesn't automatically rebuild it every time there's a change. Again, that could be achieved using a simple script.
I'm not too worried about the cross-compilation rotting since we have to use it to make svm builds.
I didn't get to (1) (though I started working on it, with the
cross-fasdump branch) but we did get pretty close to (2) and (3), and
it would be nice if we didn't regress to having to manually run
multi-stage builds every now and then.
Well, I'm open to suggestions, but I am very reluctant to significantly increase the complexity of the build system to achieve it.
> - The cross-compilation targets have been divorced from the main flow.
> When cross compiling, only cross-host is run on the host machine.
> cross-target must be run separately on the target machine.
Is this different from before? I thought that's how it already
worked (at least, that's what I remember from when I did this).
No, sorry, the cross-target target was tightly coupled to cross-host so that they ran sequentially on the host system. This kind of defeats the purpose.