Some more thoughts on library organisation. First, Felix code is *platform independent* (PI) if it just contains calls to functions like sin and cos.
It is *platform specific* (PS) if it contains calls to, say, functions available on Posix, but not on Windows. Platform specific Felix generates the *same* C++ code, independently of the platform (the C++ code, however, will either not compile due to lack of header files, or, the result will not link). Thusly: both PI and PS Felix generate platform independent C++. It is "portable* (PO) if it contains variants for each platform, selected by conditional compilation. Portable Felix code generated *distinct* C++ code for each platform. Felix code which is the same for all platforms but which calls other Felix code which is PO is itself platform independent, but as whole the code is platform dependent. Felix code can also call C++ code which is PO: faio and demux are examples. Here the platform specifics are wrapped in C++ (although, for faio some of the wrapping is also in Felix). Typically such code uses a common C++ interface to variant implementations. OK, so the question here is: how to organise the Felix library. We have lib/std for PI code. But I have just put lib/std/posix/signal which is PS code. It isn't in lib/plat! Because that contains code which is generated to have the same interface on all platforms but platform dependent implementation. Note also bindings for gmp, gsl, etc etc are now to be considered platform independent, even though the result won't run unless your platform has these libraries actually installed! I am still thinking. Ideas welcome! Generally we use *.fpc files to map platform specifics into platform independence: eg you say "requires package gmp" which is PO, and use gmp.fpc to map the abstract requirement onto platform specific details (how to link, where are the files, is it even installed?). But what of the converse? Given some code "predicting" what it depends on (requires posix, requires gmp, requires LGPL licence agreement .. etc). Oh, here is one for Erick: I am tired of changing the build system when I reorganise the library. I tried to write a "copy_dir" function in Python but couldn't figure out how to do it. Basically I just want to copy src/lib to build/release-optimized/lib, including any and all subdirectories. Python's os.walk looks nice but typically the data structure is all wrong: it isn't suitable for a recursive descent. The "dirpath" field of the result has too many leading components and there's no easy way to strip them off and prepend "build/release-optimized". Another one for Erick: is fbuild using spks at all? If not, and I suspect not, I can remove all the spkg tangles from lpsrc, and possibly then remove some more files altogether. In addition, a mod to flx_pkgconfig so that you can put BOTH unix and windows link lines into the one fpc, and use a command line option to choose which ones to use (or compile the platform into it). This would mean more *.fpc files could go directly into the repository. [Is "config" even tracked?] I'm moving towards *selecting* from pre-built files rather than generating them (the selection depends on a generated switch). -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
