The first commit of the reorganised system is now done.
I have NOT tested if the install process works (in fact I'm pretty sure it
doesn't).
The new install concept will not put libraries into /usr/local/lib or
executables
into /usr/local/bin. I hate polluting those directories. So you should do this
instead:
LD_LIBRARY_PATH=/usr/local/lib/felix/felix-latest/host/lib/rtl:$LD_LIBRARY_PATH
PATH=/usr/local/lib/felix/felix-latest/host/bin:$PATH
if you want to use Felix provided tools directly from the command line,
**including** flx.
As an alternative, you can copy flx where you want it, make a symbolic link to
it,
or write a bash script called flx that invokes the binary, and then do all your
work
using commands like
flx webserver ..
flx scoop ..
flx flx_cp ....
"flx" should set the required paths.
For developers C++ compilation now requires TWO include directories:
-I/usr/local/lib/felix/felix-latest/host/lib/rtl
-I/usr/local/lib/felix/felix-latest/share/lib/rtl
There is no C++ in config/target anymore, the directory
/usr/local/lib/felix/felix-latest/host/config
is exclusively for *.fpc files applicable to the current host.
[The subdirectories unix, win32, macosx are gone too]
Down the track the whole source will be shared, i.e. put in share,
so you can build multiple configs, using host felix, without needing
the Git repository.
===========================================================
Now: the impact on litterbox package tool I see as follows:
First, there's no place at the moment for "add on packages".
We need to discuss this. When Felix is upgraded or a new config is
built, we do NOT want to have to reinstall all the packages
(unless it is necessary). Bindings to libraries like gmp aren't likely
to need changing.
On the other hand there are now TWO kinds of location to install
Felix code:
(1) If you install in share directory, everyone using it gets the package.
In an enterprise environment, a single source code update will automatically
propagate to all users (because "flx" will auto-rebuild programs that are
modified,
and autorebuild if the core is changed as well).
So that's an administrator upgrade.
(2) If you install in a configuration such as "host" only people with access to
that
particular config get the upgrade. If the config is in $HOME only YOU get it.
If the config is in /usr/local everyone with an account on that machine gets it.
So scoop will need switches or whatever to tell it where to install a new
package.
Similarly, "flx" will need a switch to allow it to switch to a non-default
config.
Basically
--target=host
is the default (and currently hard coded which needs to be fixed). Switching the
host is NOT the same as switching the felix install like:
--test=build/release
or using FLX_INSTALL_DIR environment variable. At present the target is just
the name of a subdirectory of FLX_INSTALL_DIR containing a config.
This isn't so good because it means the build directory must contain both
the target and the share code: you cannot make a $HOME/felix/mytarget
configuration without also copying the whole of the shared code
(or at least using a link).
Really the target config should contain a "pointer" to the share directory
from which it was derived.
--
john skaller
[email protected]
http://felix-lang.org
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
