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

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

Re: [MIT-Scheme-devel] A tale of four builds.


From: Matt Birkholz
Subject: Re: [MIT-Scheme-devel] A tale of four builds.
Date: Fri, 4 Oct 2013 11:30:16 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Fri, 4 Oct 2013 13:41:41 +0000
> 
> [...]
> One thing we ought to be able to do is use different source and object
> trees.  That way, we could have one object tree for a (cross-compiler)
> toolchain, and one object tree for the target, and a single makefile
> to regenerate everything.

Yes, no tossing!  If the cross-compile dies, it is nice to still have
the host .bcis and .coms around for debugging and re-building the
cross-compiler.  Then to just say `make' and have the modified files
automatically re-compiled and a new x-compiler.com dumped (kicking off
a complete re-cross-compile?) would be sweet!

Are you thinking: VPATH support in compile-file?

I was wondering if the cross-compiler needed to be dumped out as fasls
at all.  Just (load "make") and (disk-save "x-compiler.com").  With
debugging onboard too, it would be debuggable even as it is dropping
target .bins, .coms and .bcis (.mocs and .fnis?) into the build tree.
The "object tree" is the band.

> I would like to be able to run a program without a macro expander,
> compiler, &c., in the address space, [...]

This is the same address space that comes in 64bit quantities now?
How about shaking such things out?  You will want to do that
aggressively anyway if you are trying to fit into tiny hardware.

> Fixing the system so that loading without compiling and loading
> after compiling have the same semantics is worthwhile; eliminating
> support for a distinct compilation step altogether is not.

You will have to limit macro expanders somehow.  Syntaxing in a fresh
environment and discarding that environment afterward is going to make
the semantics match?  You'll just ignore side-effects beyond the
discarded environment?  ?

We cannot eliminate separate compilation while we rely on it to
fasload a boot-compiler, but we can reserve it for that purpose and
forget its limitations outside the boot-dirs.

>    If there is any objection to moving the star-parser into
>    runtime/, now is the time to stop me. :-)
> 
> We ought to be moving stuff *out* of runtime/, not into it.  There's
> already too much crap there.  Only stuff that is an important part of
> a running Scheme program should go in there, really.

Yes, an "inner" runtime.  Star-parser needs an inner runtime
loaded/compiled before it can be loaded/compiled.  The users of the
*parser syntax also need an "inner" runtime, but it is not the same
one.

We don't have to shift the bulk of runtime/* into miscellaneous/ (or
explode it into e.g. star-parser/, genio/, threads/, etc., etc.) to
get the right "inner runtimes".  The load/compile process already
arranges them.  Just replace runtime.sf and runtime.cbf with a
compile.scm script that compiles&loads file-by-file per runtime.pkg.



reply via email to

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