On 30/08/2014, at 5:53 AM, Martin DeMello wrote:
> That sounds like an excellent change! Personally as a linux user I'm happy to
> add things to my $PATH to find a binary, but would prefer the binary had some
> fixed, internal way to find the rest of its stuff, either by writing to a
> config file in a known location or at the very worst by a well-documented set
> of environment variables I would need to set in my .bashrc.
The latest commit does the following:
The host/plat/config.flx file is gone.
This was a platform dependent library file which encoded the
configured installation directory.
Instead there is a platform *Independent* file
share/lib/plat/config.flx
containing a function which does the following:
1. FLX_INSTALL_DIR is set to /usr/local/lib/felix/felix-<version>
[This is a bug, it should be felix-latest IMHO]
2. if $HOME exists and $HOME/.felix/config/felix.fpc exists
and it contains the a line starting with exactly
'FLX_INSTALL_DIR: '
excluding the quote makes, the rest of the line is used to set
the variable FLX_INSTALL_DIR.
If the above mentioned file doesn't exist a warning is printed.
I think the file will become required and the warning will change
to a program abort but we'll see.
3. If the environment variable FLX_INSTALL_DIR is non-empty
string its value is used to set the variable FLX_INSTALL_DIR
The function returns a record:
(
FLX_INSTALL_DIR=FLX_INSTALL_DIR,
FLX_TARGET_SUBDIR="host"
)
The client program, for example flx, can then override the
returned value in some way it likes. At present flx has two options:
4. flx --test=dirname ...
resets the install dir to dirname. I use this testing, often saying
flx --test=build/release ...
5. flx --felix=filename
This reads a configuration file which may override the install directory.
Typically this would be
$HOME/.felix/config/felix.fpc
i.e. the same file used by the config function.
I could think about looking for ./felix.fpc as well,
or perhaps ./project.fpc so each directory you're
working in could have a "project" file.
================================================
So: THIS IS A TEMPORARY HACK. It is part of an "Agile"
transition to use a different layout mechanism.
With these changes you can use
make PREFIX=/home/myself install
to do an installation, for example. Being able to install felix somewhere
that does not require administrator privileges is important.
In the new system there is no "installation directory".
instead the various "parts" of Felix can be individually specified.
There will be a "standard layout" which simplifies this,
roughly the existing layout using FLX_INSTALL_DIR.
There are several reasons for this.
First, if you have a read only shared Felix system, perhaps on
an enterprise wide server, you still may want to build a target
which isn't supported. For example, I myself want to build
a clang and gcc based target so I can check both work.
Someone else may want to build a cross compilation target.
At present the target is a subdirectory of the install directory.
So you cannot build a new target privately without copying
the install directory (yea, on Unix you could use a link).
Another problem is the standard library is cached, and if you change
anything the whole library has to be recompiled. This takes
ages, and I myself want to switch between the build/release
version for testing and the installed version. So I want to allow
for independently specifiable cache locations to avoid rebuilding
the cache every time I change something.
However there is another, much more important reason:
PACKAGES
Where do we put them? The answer in the default layout is probably
/usr/local/felix/site-packages
following Python. Or
/usr/local/felix/share
or something .. :)
But of course .. YOU cannot write there, only the admin
can. So we need a way to specify a search path for libraries.
[I mean, not every time on the command line!!]
Also whilst Felix code is read only text files, C++ code may want
objects, object libraries, and shared libraries to be built and these,
like the core RTL, need to be split off away from the universally
shared source code, so that each target gets its own binaries.
Its important packages do not live in the core Felix directory,
because when you upgrade Felix (without a version change)
the directory is deleted before installation (to make sure it is clean).
OTOH when you install a new version, the directory won't have the
packages in it and you don't want to have to install them all again.
So the packages should live outside any particular Felix version.
Unless they're core packages.
To make all this work I want a single point layout control file.
Finding and specifying it will be a PITA and a source of error
and confusion but once it is found everything can be made explicit.
[IF felix every gets installed into /lib then the config would live in /etc
on Unix. in fact I have my eye on the idea that Felix script should
be used for Unix init processing. The Sys V method with bash is
unmaintainable, upstart is a bitch, etc. Having a type safe language
to control system init makes sense. Having a fully compiled to binary
language for a fast secure start does too]
--
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
