So some issues with dependencies.
First, if you say
include "fred";
this will include either
path/fred.flx
path/fred.fdoc
depending on which has the latest timestamp. This is a nightmare.
The dependency file just says
path/fred
The *.flx file is the straight code, the fdoc file has extra literacy support,
it allows
headings and text etc, and is a standard *.fdoc the webserver can display
with special constraints on how the code has to be presented.
Secondly, AFACS, when searching the path, the directory containing the
files is fixed when one of the above is found, they can't be in distinct
directories.
So, to do a dependency check one has to repeat the compiler's resolution
algorithm. So for example if you change either of fred.flx or fred.doc, your
binary
is not up to date anymore, even if you change the one that wasn't previously
the latest.
This isn't a bug or a theoretical issue but it makes "make like" dependency
checking impossible because code A can depend on either B or C, depending
on B or C, without changing A.
On the other hand there's a serious bug with the method if the path changes.
In that case you're now resolving to different files from the ones actually
used.
This would be a problem with any C compiler as well.
To solve this, we have to store the search path as well. If that changes,
the files on which your code *might* depend could differ.
It gets worse. Felix allows you to specify the cache location, in fact there
are two caches: binary and text. The binary one contains binary stuff
which is machine readable but not human readable, the text one just
contains text files. What's more the final output binary can be in another
place if you use a -o switch. There's no way to work back from the final binary
to find the dependencies reliably.
Now, lets assume the standard cache structure cache/text, cache/binary, then
changing the cache location shouldn't matter. It doesn't matter where the binary
goes as long as the cache used to make it was specified. Then, we know where
the dependency file is.
So lets get back to what happens if you use the default output location, which
is in the cache. If you switch to another cache, that's cool, you just get a
different
binary. So, we can fix the problem of where the binary goes by simply always
putting it in the cache first then copying it. Then the output location can be
checked against the copy in the cache. In fact, if the cached copy is up to date
when you switch caches, the binary can just be copied over the external one
without recompiling anything.
All of this is dropping out of trying to figure if library caches are up to
date.
It's even more complex than I like because "flx" has to duplicate the dependency
checking done in flxg, just to see if flxg should be run.
Its also a real pain because if I get it wrong, then since I'm working on the
build process itself, I can easily get snookered: have to fallback to the
Python build. Which takes hours .. the problem I'm trying to solve!
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
