I am currently able to do this:
# build the Python based Felix
make build
# OSX bootstrap
make bootstrap
# upgrade
rm -rf build/release
mv build/trial build/release
# Again
make bootstrap
And so on, as many times as you like.
Running the bootstrap process takes the Python based build and uses it
to create a Felix driven build, however the conversion is incomplete
because the tools used to actually make the new RTL etc are from
the Python build.
So we repeat the process, now using Felix built tools to rebuild
everything.
There's no assurance exactly how many cycles this takes to reach a fixpoint,
however it does appear to. The result of several iterations of the above
can be installed and used (with a couple of restrictions since not quite
everything is built at the moment). However the webserver works,
and that's a pretty major program.
Limitations
========
(1) At present the Makefile hard codes toolchain_osx_clang because I'm not
sure how to make it parametric. You'll have to edit it to duplicate the
bootstrap
on another platform.
(2) The compiler flxg is NOT bootstrapped. It's an Ocaml program,
we don't have Ocaml builders in Felix yet (only the Python code can do it
at present).
(3) The configuration is just copied: host/config/*.fpc and
host/lib/*.flx and host/lib/rtl/*.h(pp). We need a tool to generate
configurations. Scoop needs something too.
(4) Misc files like misc/vim/felix.syntax are not installed.
A few tools aren't built.
Future
=====
I have just completed (I hope) refactoring "flx" so it a single line
program that just called "flxrun" from the library passing the
command line arguments as a list. Other tools like "flx_cp"
can be adapted to use the same technique. It create an issue
regarding file system layout and modularity, but it works.
With such changes the lines of the Makefile can be replaced
by simple Felix script.
I am in fact thinking to go a small step further: register the tool functions
in a lookup table, and then use an entirely dynamic lookup. If a tool isn't
found, just call the OS shell instead. Then with some fiddling "shell script"
becomes part of Felix, and we can also write a "REPL" like shell.
In any case the bootstrap can be "build in" to Felix better. When we get
a config tool this will allow generating cross compilation targets.
[You can do this now by manually setting up the config].
I'm also thinking "why do *.fpc files uses a weird format, similar to
pkgconfig files?" Why just use Felix script?
Part of the answer is: Felix cannot load multiple files which all
define the same variables. This is part of the global namespace
hijacking problem. Ocaml solves this with a -pack option but I hate
that. Roughly we'd "automatically" wrap certain files we loaded
as Felix with a class like:
import "fred";
-->
class fred {
#include "fred";
}
Again, Ocaml modules do this: the filename acts as an outer module
name. I have resisted doing this in Felix because it interferes with
symbol scope control: instead of being able to freely cut and pasted
into include files, they now have semantics.
Still the current system sucks: file A can refer to file B without either
including the other provided file C includes them both. This is fine
from a "everything is one huge text file" concept where names
are packaged in classes, however not when you say
open B;
in file A, it makes B open everywhere.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
