Well, to solve the problem with flx and toolchain plugins, I am just
sourcing the common toolchains (i.e. as includes).
Flx is edited now to use toolchains instead of caling the compilers
through the lower level generic compiler library functions.
I have temporarily added a TOOLCHAIN variable to the plat/config.flx
record to specify the toolchain (this will be replaced by using a package
file).
So I hoped to get rid of the compiler stuff from the config record,
and eventually get rid of the config record altogether.
For example
config.EXT_SHLIB
will be .dylib on OSX or .so on Linux, but the toolchain object has a function
for that so we don't need it. Right?
Sometimes I HATE grep ...
/felix>grep -r EXT_SH src/*
src/lib/std/dynlink.fdoc: modopen$ lib,
modulename+#(Config::config).EXT_SHLIB, modulename;
.....
If we load a plugin toolchain we can find the appropriate extension for shared
libraries.
The problem is .. the plugin is a shared library, and so we have to know the
extension
for shared libraries to load the plugin that tells us the extension for shared
libraries .. :)
The hack used in flx to just "compile in" the standard targets is OK because it
doesn't preclude loading arbitrary plugin tool chains, it just make
bootstrapping
from the Python build simpler. But we cannot use that hack in a general library
routine.
The only viable solution is again a config package.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
