Mike: we need to agree on a schedule and process for moving
pkgtool into the core. I can do this, but it may disrupt your work
so its better if you do it. I would move pkgtool.flx first and leave
scoop in demos to start.
However before doing this there's a discussion to be had:
should we??
The current model has a big advantage. Its entirely separate
from the core Felix build and install process. The two
components: pkgtool library and scoop executable can be
bootstrapped into the system by running setup on the initial
manually downloaded package. The download is currently
effected by Git.
Once bootstrapped, scoop and pkgtool can self-upgrade,
as well as installing other packages.
That means the bootstrap version in Felix repo can be
behind the most up to date version: as long as the API
is consistent enough for the bootstrap to load its own
upgrade, you don't have to post the upgrade to Felix.
Now, if you put pkgtool or scoop, or indeed anything
else such as for example "re2" (Google regexps) into
the litterbox, and it was originally part of the core,
we have a conflict: upgrading from the litterbox
clobbers the core, but reinstalling Felix clobbers
the package version.
==================
Now, in general, I think there is a right way to handle this.
What we do is we install
$INSTALL_ROOT/boot-felix
so the core build is installed in a special directory for a boot
version of Felix. No versioning!
The boot version of Felix is used exactly once.
It is used to allow the boot versions of flx, scoop, etc to
build and install the REAL felix.
ALL of it. Not just add on packages.
The REAL Felix has to be versioned to the extent that,
you can use the current install to upgrade to a new version.
the old version must remain intact, and it is used instead
of the BOOT version (which is now deleted).
My vague organisational thoughts are:
1. The original BOOT version you build is installed in $HOME.
2. The current REAL Felix is then built using that and installed
in /usr/local
3. Once the /usr/local version is judged OK it is upgraded
to /usr
4. you can continue to build the head in your work space
and install in $HOME if you want to play with development.
5. When you are happy you upgrade /usr/local, possibly
with a distinct version install ie. /usr/local/lib/felix/felix-1-1-9dev.
6. You can upgrade your /usr/local system with scoop.
The scoop you use comes from /usr!
7. So the basic rule is: the /usr install of Felix is the system
Felix. Its reliable. Its not upgraded often. Its primary use
is to run the package manager to upgrade versions in /usr/local.
So vaguely:
BUILD: The $HOME version of Felix is for Felix developers.
HOST: The /usr/local version of Felix is for programmers using Felix.
[Or C++].
TARGET: The /usr version of Felix is for running Felix.
RUN: the run version of Felix doesn't exist, it consists
of ordinary binary stand-alone executable and DLLs.
For example /usr/bin/flx_cp.
These would normally go in /usr/bin or /usr/lib on
a Debian distro (as opposed to /usr/lib/felix/).
============
The overall model is vital to properly staging Felix
digestive process. The install model conveniently
agrees with the cross-compilation model.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
