So I am adding a new switch to flx, somewhat confusingly
--felix=filename
[confusing because unrelated to --nofelix switch]
The file should contain flx_pkgconfig like fields.
Here's an example:
install-dir: build/release
I'm decoding these at the moment, shown with actions:
| "install-dir" => config.FLX_INSTALL_DIR <- data;
| "target-bin" => config.FLX_TARGET_SUBDIR<- data;
| "share-dir" => control.FLX_SHARE_DIR <- data;
| "cache-dir" => control.CACHE_DIR <- data;
| "output-dir" => control.OUTPUT_DIR <- data;
So basically, this file is like a Windows @response file at the moment
that just sets one or more variables you could already set with
other switches. There is one new variable, FLX_SHARE_DIR which
if not explicitly set should default to
FLX_INSTALL_DIR/FLX_TARGET_SUBDIR/"share"
i.e. where the read-only shared sources live. I'm decoupling
that from where the target lives. So at present everything
should continue to work exactly the same if you do not use
this switch, and it should work exactly the same even if you do
provided the fields are understood to set the corresponding
switches as if you set them on the command line.
One immediate benefit to me is I can have two files in my working
directory:
DEVELOPER.fpc
INSTALLED.fpc
and have them nominate the build/release and /usr/local/lib/felix
builds respectively AND specify different caches. So I can then
switch between the two without having Felix continuously rebuilding
the cache on each switch.
Another benefit, and the main purpose, is to allow an a more flexible
configuration for an enterprise deployment. At present if you have a shared
FLX_INSTALL_DIR the sys admin HAS to build the target subdirectory for
each architecture because admin privileges are required to write to the
install directory. But the user should be able to do this. Anyone should
be able to build the binary/platform dependent bits, and configure it
as they please, using the shared sources.
In particular the admin should be able to build stuff with a private
copy of a new upgraded sources and check them out before
releasing them. So decoupling the shared sources from the binary
targets entirely is sane.
Down the track (and not very far down the track) this allows solving another
headache: how to install third party add ons. For example there are add ons
for GMP and GSL (the Gnu libraries). We can't put these in the core easily
because a new Felix install will wipe them out. It's also hard to autoconfigure
arbitrary add ons.
With the --felix file, the problem is "solved" by not solving it, but by making
the client solve it. I just add a field for specifying say a list of directories
to search. Then its up to the user how to do this.
Eventually, flx will probably search for some default --felix file and use that
if found INSTEAD of the current defaults, however I will transition into this
model slowly enough stuff doesn't break too hard. In particular the Python
bootstrap has to continue to work.
--
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
