Just a quick note on the new system. to make both C++ and Felix compiles work
we now need TWO pointers to directories:
(1) A pointer to the platform independent library interfaces: share
(2) A pointer to the platform dependent library interfaces: host
[The name "host" will vary later if cross compiling]
The binaries are always platform dependent so we only need one pointer for that.
So I want to explain carefully what "platform (in)dependent means.
If you have alternate (conditionally compiled) code for Windows
and Linux, that code is platform *independent*.
It's probably more precise to say "platform adaptive" meaning it adapts
to the platform. However, this is true of ALL code: the compiler adapts
it to the target when compiling to binary after all!
A file which will only work on Windows is platform dependent.
The same file with a guard that conditionally compiles it is in a weird state;
it will work on Windows, and it will *compile* properly, to nothing, on Linux
too,
but clearly it won't work on Linux.
Now, if we have a second file with a guard for Linux, then and include BOTH
files
in our program, one of them will compile correctly and the other do nothing, so
the result is again platform independent.
Now remember if we physically include the contents of both these files
including the guards, the result is again platform independent.
So it would be "nonsense" to regard a mere refactoring as resulting in
a platform dependent code.
On the other hand if you have a file that includes only the Windows version,
it will not compile on Linux -- assuming you actually call a function in that
file. So that file is platform dependent!
There's another aspect of this: code which "optionally" uses some feature
is considered correct if the feature is present or absent.
So now, what can we say?? Well, for a start, the files that fixedly set the
conditional compilation switches, typically called configuration files,
those files are clearly platform dependent. Sometimes we don't need these
because
(a) the compiler sets macros, and we can use those
(b) the macros are set on the command line
The bottom line here is like this: if a file can be shared, it is platform
independent
and goes in the share directory. if a file is *generated* by the configuration,
it goes
in the platform dependent directory (currently, "host").
This means, for example, that the src/config directory is platform independent:
src/config/indie-package.fpc
src/config/win32/dl.fpc
src/config/unix/dl.fpc
Here, we have a Windows setup for dynamlc loading using LoadLibrary etc,
and a Unix setup using dlopen. This is platform independent because the two
variants are
both present in clearly marked subdirectories. Now when we make an actual host
config we pick one and we get this:
host/config/indie-package.fpc
host/config/dl.fpx
where either the unix or windows dl package spec got copied in. In other words
it
got generated. So *this* config is conditionally "compiled" from the platform
independent
source in some sense and is itself platform dependent.
So the model is: it goes in "share" if it is fixed, and "host" if it is
generated.
In practice we may get some more stuff in the "host" directory than we really
should
technically by details, just to present a consistent model: for example most
Felix C++ source libs #include a config file. For most of these the config file
doesn't have any content, so it's technically platform independent,
but we have one anyhow just to get a 1-1 relation between the libs
and the config files. This means if we modify the lib to contain some platform
dependent stuff we don't have to move or create a new config file, just
generate the existing file appropriately.
Conceptually then, the whole GitHub repository is platform independent,
because it IS the shared basis of the whole system.
More generally, a better model is type classes. The class has some virtuals,
but the class is polymorphic and shared. The instances fill in the virtuals,
with specific argument bindings.
To implement this in the fie system seems tricky. The "virtual" could be links
to /dev/nul, and then you search the host then the shared directories. If you
leave
out a virtual instance you get the link to /dev/nul instead. This is different
to finding
a file doesn't exist (leaving out an interface is different to failing to
implement it!)
Actually I'm not sure about /dev/null: we may want an empty file, sometimes
that would
be OK if it has no content. but other times we actually want a file which
cannot be
opened at all (to force an error).
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
