mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] Edwin doesn't launch in master


From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] Edwin doesn't launch in master
Date: Thu, 25 Oct 2018 02:12:04 +0000

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

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

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.

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]