I'm back to thinking on architecture, esp. regarding how to install
packages. The current system is
1. /usr/local/lib/felix -- contains all Felix shared stuff
2. Within that, one directory per version, with a link to
"felix-latest" for some flexibility.
3. Within that two dirs:
share -- read only sources
target(s) -- one or more targets
The target "host" is required, but you can have others.
Targets contain:
bin, lib : machine binary code
config: package info including mappings to 3rd party libs
lib/rtl: configured C++ headers and machine binary
lib/plat: platform specific Felix code
4. $HOME/.felix -- transient cache
Also some config data.
It's not entirely consistent that the targets live in the same place
as the share directory. It would be more consistent if the targets
could be anywhere, you point flx etc at a target, and the target
points to the shared sources that built it and are needed for
compilation (or documentation).
The cache also has two problems. First, if you change targets
it gets rebuilt from scratch. Second, in theory it doesn't support
more than one process. Multiple users are supported because
there's one cache per account. If the cache had a branch for
each target a lot of the rebuilding would go away (however the
main sufferer here is as a developer).
Using the target as an additional qualifier makes some sense
but the file names would be horrendous. You'd have
$HOME/.felix/cache/target/userfile
which looks OK until you realise that "target" and "userfile"
will BOTH be absolute filenames so the actual name of a file
in the cache will be:
/users/fred/.felix/users/fred/host/users/fred/filename.o
for example .. the name contains the top level /users 3 times :)
The overall structure makes a local felix target unusable.
Assuming /usr/local/lib/felix/... requires root access
and ordinary user has to use a COPY of the share directory
just so the target they're building is in a writable location.
Worse .. there's no deemed place for add on packages.
These would tend to be independent of the core Felix.
So the shared source should probably live in
../felix/packages
If the package has binaries or C++ headers,
where would they go? They're target dependent.
And so the *.fpc config stuff is too.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
