The filesystem reorganistion is well under way. At present I'm modifying the
Python build code to split everything into two directories:
ROOT/host # platform specific stuff
ROOT/share # platform independent stuff
The name "host" means "this machine". To use Felix you SHOULD have at least
a "host" build, so you can compile Felix for "this machine". You need this
to make tools to use on your machine, EVEN IF your final target is another
machine.
For example if you're building Windows apps on Linux using gcc cross compiler,
or building Android apps on Linux or iOS apps on OSX, you still need a Linux,
Windows, or OSX host build first.
The "host" build is the one most people will install using a package manager.
ONLY the host build can be easily configured. It is possible to test for
presence of header files and functions when targeting a different platform,
but you can NOT do things like calculate the size of a void* by running
a program like:
#include <stdio.h>
int main() { printf ("%d",sizeof(void*)); }
because you're compiling for a different box than the compiler is running on.
So if that information is needed it has to be specified "manually".
The plan is to set this up for common targets so the "specification" just
selects
a preconfigured directory.
An important goal of the split is to allow compiling for multiple targets:
obviously your host and your cross compilation target, but "target" can
mean more than a different OS. It can mean a different compiler, or even
the same compiler with different switches (eg 32 or 64 bit, or even multiple
CPU's on a Mac).
And as a special part of this goal, once you have installed Felix, the
share directory should contain the entire platform independent source,
including not just the Felix code but also the C++ (and eventually the Ocaml
as well). So you can
(a) build a run time for Felix on another platform
WITHOUT requiring the repository image.
(b) go even further and build a Felix install for another platform.
Note (b) is MORE than (a) because (a) simply builds some C++
libraries (headers, dlls, archives) which so Felix generated C++
can be compiled and linked against it, whereas (b) ALSO builds
the tools like "flx" which allow the target platform to be a host platform
for a user on that. In other words (a) is just cross compilation at the C++
level whereas (b) is a full "port" of Felix.
Porting requires more work by the programmer because of the point above:
some config details cannot be established by "suck it and see" method.
Note that soon the autconfig will be doable in Felix, instead of Python.
Once that is working we can actually port Felix to any platform by
porting the autoconfig program. this will have less requirements than
porting the whole package. Also there will be a program to help
manually port things (question and answer type of thing).
If all goes well we can eventually drop the need to use any Python in
the build (although we might retain the config stuff as a quick and dirty
way to "port" the system to a new platform).
The only thing that will be needed is Ocaml and of course C++.
Ocaml cannot be eliminated from a full developer port.
We would either need
Ocaml -> C -> cross compiler
or
ported bytecode interpreter for Ocaml
or
build ocaml on the target ourselves
The latter is quite doable.
FOR NOW: if you're developing any build tools (that means YOU Mike!) stuff
will probably break. Most of the changes are just moving files about, which
means
various paths will have to be changed. Compiling *felix* should just work
however.
To make a "single point" method of choosing builds seems to require a couple of
changes. First, the "host" config probably should "point at" the platform
independent
directory it was derived from. you need BOTH directories to do anything. Note
that
even some Felix code is platform dependent, e.g. the floating math formatting.
And of course the config! The version.flx file is generated but is shared.
The second problem is that I do NOT want to install ANYTHING outside these two
directories. No binaries. No shared libraries. No headers or archives.
If I do that you will have to say:
/usr/local/lib/felix/felix-latest/host/bin/flx
just to run "flx". There are two solution: make the user write a shell script
and install it where they want (possibly $HOME/bin). Or just give up and
actually install "flx" in /usr/local/bin. Or you can tell the user to say
setenv PATH=/usr/local/lib/felix/felix-latest/host/bin
setenv LD_LIBRARY_PATH= ...../lib
To make this a true "single point" install, we have to decide how to run scoop.
One way is:
flx /usr/local/lib/felix/felix-latest/share/tools/scoop ......
which is the same problem as above. However, it's worse because there's
no environment variable for finding Felix programs (library files, yes, but not
the top level program).
Another solution is to merge scoop and flx into a single program, i.e. to make
"flx" the "shell" for using Felix. "flx" is already being modelled like this,
by moving
parts of the code into the library, and also using plugins.
We have to remember the main reason for using "flx" is simply to avoid a whole
crapload of switches and environment variables and let "flx" do it for you.
There's one remaining major problem I don't know how to solve (HELP!!!)
When we wish to make "usual" system tools, like "flx_cp" which is a better
version of Unix copy "cp", we want to make these available "in the usual way"
as binary programs. Or, we may be making a "usual" library (C callable).
Of course then the user of THAT stuff knows nothing about Felix,
so if there are dependencies (plugins, header files etc) we have to make
sure they can be found.
For example: to run the webserver in "plugin" mode we have to actually
find the plugins. Since we name them with a full path we have to conspire
to give that path to the webserver executable. But there's MORE. Some plugins
load other plugins, so the webserver has to distribute it. This can be done too.
What can NOT be done so easily is: the plugins will be needing to load
DLLS (i mean, load time dynamic linkage not run time by dlsym).
It will find these on the LD_LIBRARY_PATH. And you can NOT specify that
INSIDE a program (at least on OSX you can NOT change the dynamic linkage
path for security reasons). You CAN call an executable with a different path
via the shell or exec family functions, but you have to go through the OS.
this is NOT a problem using "flx" because it sets the variables.
But it IS a problem with a standalone executable .. because actually it isn't
a standalone executable.
NOTE that I have already demonstrated technology to "freeze" a program:
that is to force plugin linkage to go to a statically linked plugin. With that
operational, all the dependent library code can be linked in and make
the standalone genuineuly standalone (provided of course we're not
doing actual programmed dlopen() of a file whose name is read
from a text file so we couldn't know about it in advance).
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
