Well ... now I have documented "flx" it is time to break it :)
Here's the story. At the moment flx has code to load toolchain
plugins dynamically, but it's never been tested.
On the other hand flx_build_rtl does this right now.
So we think it works :)
The toolchain is selected based on a configuration package.
Now, it's important "flx" is a statically linked stand alone executable
that doesn't need any LD_LIBRARY_PATH for normal operation,
nor need to do any dynamic loading. Otherwise we'd have all hell
breaking loose trying to recouple it, since the PATH controlling its
toolchain load may not be the one we need to run the target.
The way to have your cake and eat it too is to make flx do dynamic
loading anyhow, but then uses a pre-loader. We have the technology
to do that. The toolchains get generated as both a *.so/dyld/dll and also
as an *.obj/os file, and then a thunk program is used which causes these
to be statically linked.
This means we will have two versions of flx:
flx -- same as now, only uses statically linked plugins
for gcc/clang on linux/osx
dflx -- always dynamically loads plugins
A big advantage of all this for me is that the compile time for flx will be
reduced.
The tricky bit is that the toolchain plugins must already be built to make
flx work at all, but flx is what we use to build them. Bootstrapping is such
fun :)
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
