On 30/08/2014, at 9:53 AM, Martin DeMello wrote:
> Another idea is for the config file to *always* live in
> $HOME/.felix/<somewhere>, if necessary copied in from a fixed (written once
> at install time and never modified thereafter) file in /etc/felix, but
> maintained in .felix thereafter.
Well its not "another" idea: I did write this:
"""
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.
"""
>
> Actually, my somewhat more drastic inclination (you will probably not agree!)
> is to get rid of the ability to use felix as a systemwide scripting language
> altogether, embrace the fact that it generates native executables, and let
> the default be for developers to always install felix as user, set up their
> dev environment, and use it to create executables which need no reference to
> the felix compiler to use them.
You can do this now. If you use --static switch, you get an executable. At
present it will
be hidden in the cache, but you can change that with the -od . switch:
flx --static -c-od . hello.flx
will produce an executable hello (or hello.exe on Windows) in the current
directory.
However, remember Felix is actually designed as a *library* generator not a
program generator. The fact it can generate programs is actually a minor side
effect of the design.A program is the side effect of library initialisation
code,
when the library is combined with "flx_run" mainline to run it.
As an example, the webserver flx_web is built as a short program
which loads a system of plugin libraries. So we need to be able to
build these plugin libraries: they're shared libraries not programs.
Actually dflx_web loads these with dlopen(). But flx_web uses
an emulator to trick the system into using statically linked modules
instead, so flx_web is a self contained executable.
The flx program does this too: there's a dflx which loads toolchains
dynamically, but a flx which finds common ones like gcc and clang
statically linked (so operation is reliable).
FYI in both cases the program logic is unchanged. The program
thinks it is doing dynamic loading. However a wrapper is used
to "preload" certain libraries, which are static linked. So for any
program using plugins, you can freeze any set of plugins
into the executable with a suitable wrapper.
however there IS another problem with $HOME/.felix/config/felix.fpc just being
the single mandatory layout control file: Felix is designed to support cross
compilation.
You will always need a "host" target for your local machine to build the
development tools, but you may also want to build other targets:
Android
iPhone
are obvious examples. Or if you're on Linux you may also want to build
Windows
using a gcc based cross compiler.
These are extreme examples, less extreme ones are building with both gcc
and clang, or building a debug and non-debug version of something,
or building a --usage=production version as well as a --usage=debug
version (use different optimisation switches).
Or what I do: I have an installed Felix AND one in build/release
that I want to test. The bootstrap process actually requires an
installed version to build the a new one, for obvious reasons.
Obviously with multiple targets a single control file is not enough.
but the bottom line is I do believe a single initial control file
is needed instead of a lot of hacks finding things.
Another example I just ran into: for the SDL based GUI to work
we need some fonts. Where these fonts live varies from
platform to platform. We can use the configuration database
at run time to find them .. but where is the configuration
database? if you hate a font, you want to be able to run a
GUI program with a font you like .. :)
> Anecdotally, I have never had a good experience developing in ocaml until I
> gave up on the system install and switched to exclusively using opam as user,
> with both the compiler itself and all the installed packages maintained under
> $HOME/.opam. As a developer this model works beautifully, and realistically,
> the target audience for felix is 100% developers now and for the foreseeable
> future.
Of course, Felix is a programming language and development system, so the target
is clearly developers.
And I tend to agree that to make the whole thing work nicely one needs a
package manager.
Mike Maui's original scoop tool was a good start, but it couldn't really handle
the separation between the platform independent sources and target
relative binaries, nor was there really any systematic way to do things
like compile C/C++ parts of packages.
There still isn't but I'm working on it :)
--
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
