Felix now has this:
class Config {
typedef config_type = (
FLX_SHARE_DIR: string,
FLX_TARGET_DIR: string,
FLX_HOME_DIR: string,
FLX_PROFILE_DIR: string,
FLX_CONFIG_DIR: string,
FLX_CACHE_DIR: string,
FLX_OUTPUT_DIR: string
);
SHARE: directory containing shared universal resources "text only"
[white lie: can also contain *.jpg etc for website]
TARGET: directory containing target specific resources including binaries
HOME: usually $HOME/.felix, top level of directory Felix can get
personal details from, and which it may write to
PROFILE: usually $HOME/.felix/config, the directory containing
personal package control files (*.fpc)
CONFIG: directory containing target specific package control
files
CACHE: place to read and write cached binaries
OUTPUT: place to put generated code, usually C++
This list isn't complete. Note the pseudo variables FLX_INSTALL_DIR
and FLX_TARGET_SUBDIR are not included.
All of these variables can be set by and
(a) the environment
(b) a control file
and some can be set by
(c) command line switches.
They can be set individually, as well as FLX_INSTALL_DIR
and FLX_TARGET_SUBDIR, and HOME. However FLX_TARGET_SUBDIR
may not be set in a control file without previously setting FLX_INSTALL_DIR.
This is because there is no record of FLX_INSTALL_DIR to cascade
the setting of FLX_TARGET_DIR from.
When a variable is set, dependent variables are also reset.
So the order of setting matters.
FLX_INSTALL_DIR cascades to set FLX_SHARE_DIR and FLX_TARGET_DIR
for example.
HOME cascades to FLX_HOME_DIR and thence FLX_PROFILE_DIR.
The config control variable then cascade to other control variables,
such as the name of the grammar file, the search path for
libraries, etc. Most of my recent hacking has been getting this
cascade correct.
Here is a control file I'm using:
~/felix>cat build.fpc
FLX_INSTALL_DIR: build/release
FLX_CACHE_DIR: build/release/cache/binary
FLX_OUTPUT_DIR: build/release/cache/text
with command:
build/release/host/bin/flx --felix=build.fpc hello
More variables will be added to the config,
This is your "one stop shop" for controlling a project.
It makes all the compiles and whatever in that project
build in the same environment with a "one point"
control.
Felix looks in FLX_PROFILE_DIR for a file named "felix.fpc"
and if found processes it as a config file. It also looks for this
in the FLX_TARGET_DIR/config directory.
note that environment variables are OVERRIDDEN by a
control file. The order is:
defaults
environment
control file
command line switches
I am thinking to add a second set of environment variables such as:
FLX2_CACHE_DIR
These will override the command line switches. The reason is
if you have script, eg in a makefile, and you want to modify
the behaviour: at the moment that is invasive. This is particularly
bad if the script is Felix not bash script (because it triggers recompiles
in the code being used to compile things .. )
==================================================
Although it sounds simple there are some NASTIES floating about.
Consider this, which is actually done more or less:
build/release/host/bin/flx build/release/src/tools/flx.flx hello
Yep, that's flx building itself. The problem? The environment
controlling the first "flx" is the same as the second one.
They'll use the same cache for example.
This is a real problem for some other variables.
LD_LIBRARY_PATH is the worst.
If you have A loading B loading C, then A and B use
the SAME value of LD_LIBRARY_PATH. There's nothing
you can do about it. The only way to fix this is run C
as a separate process because that's the only way you can
change LD_LIBRARY_PATH (using setenv() in your
program code does NOT work).
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
