On 20/02/2013, at 4:40 PM, john skaller wrote:
>
> So now we would like to co-develop, so we can do this:
>
> flx base.cpp top.cpp script.flx
here we go: stage 1:
////////////////////////////////////
// mylib.cpp
#include <stdio.h>
void myfun () {
printf("Hello this is myfun C++\n");
}
/////////////////////////////
// myprog.flx
proc myfun : 1 requires header 'void myfun();';
println$ "Felix is going to call C++";
myfun;
println$ "Felix called C++";
/////////////////////////////
~/felix>build/release/bin/flx --force mylib.cpp myprog
Felix is going to call C++
Hello this is myfun C++
Felix called C++
////////////////////////
Note that at this point there is no dependency checking for the C++
code. You will have to use the --force switch if you change the C++,
unless you also change the Felix code.
Rather clumsily, this allows you compile arbitrary C++, you just need
a "trampoline" written in Felix as shown to invoke it. This ensures the
linkage mechanism still works. A bit later I might remove that constraint
so you don't need any Felix to boot the C++ code, however apart from
figuring out the command line syntax required to support that,
I will also have to fiddle the linkage to skip linking any Felix in.
For static link programs this is easy (just drop all the Felix stuff).
For dynamic link programs it is nonsense (it doesn't make any sense
to run a shared library as a C++ program, you need a driver executable).
For static link libraries, its slightly tricky, since "flx" cannot make them
at the moment. This is mainly because Felix can't either. I'm part of the
way through creating the required support so plugins all use unique names
for all entry points, so they can all be put in a static link library together.
This won't impact C++ code, I just need a way to tell "flx" to make
a static link library, and use the required too (ar/ranlib on Unix systems).
It should be easy to make it work for dynamic link libraries.
Down the track a bit more: there's a need for Felix to generate C++ callable
libraries. This can probably be done now
if you follow the (rather complex) protocol required to start Felix code up.
However we want "pure" libraries too, i.e. just sets of functions,
no thread frame, no gc, etc. Felix can generate such functions, but the
compiler cannot be told to omit the framework wrapping code yet.
It also can't be told to "bug out" if someone writes a function that
uses the (non-existent) thread frame of garbage collector.
Felix was always intended to be a library generator.
The "side-track" into making programs was more or less necessary
to test the components, and also to demonstrate what you can do
in the language.
The core tool set is now fairly good: reasonably stable and demonstrably
capable of generating quality, fast, code, so its time to start using it to
actually implement some of the original design goals.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
