Where do i put stuff?
I hope this is the right list to ask about which directories
to install things into, and about package structure. I'm having
some problems wrapping my brain around these issues, however,
the problems aren't entirely just debianisation issues.
Please excuse the long winded explanations below,
if I understood the issues well enough to give a terse
explanation .. I probably wouldn't need any help :)
To begin, the product is Felix, which is roughly
"a new programming language". More precisely it is a toolkit,
consisting of a compiler, standard library, runtime library,
wrapper generator, documentation generator, documentation,
and other such things (as you might get with, for example,
gcc, python, ocaml, haskell, or similar). The principal
component is the compiler executable 'flxg' which translates
Felix code into C++.
Note one key difference: by default, Felix targets libraries
not programs. This is because it is positioned as middleware:
these libraries sit between the application developers
framework and data types, to implement the application logic.
The Felix code is both embedded in the framework, and also
embeds application specific routines and data types.
Compiling a 'program' is actually a special case which
is handled by a driver mainline to represent the framework,
whilst the initial data types are the ones supplied
by the standard C/C++ library plus optionally some additional
interesting libraries (such as GMP, GTK, etc). Felix generates
a library with one 'main' routine which the driver calls.
The driver is similar to C/C++ startup code.
In general, clients are expected to write custom drivers
to interface their application framework to the Felix library.
In particular, this driver is responsible for scheduling
the ultra high performance user space threading system.
In theory, there are four distinct platforms involved:
1. The 'build' platform is the one you build the toolkit on.
2. The 'host' platform is the one on which the compiler runs.
3. The 'target' platform is the one on which the C++ compiler
and linker run.
4. The 'run' platform is the one on which the executables
execute.
Note this isn't just a single tool chain, the same host
should be able to target multiple targets.
Most compilers are not very good at organising this.
Felix tries to generate C++ code that will compile
anywhere, to the 'host' to keep the host and target
platforms independent.
In addition there are certain features that only work if
one or more pairs of adjacent platforms are the same.
For example the scripting harness 'flx', which turns the
system into a scripting language like Python, only makes
sense if the host, target, and run platforms are all the
same.
Examples:
[Game development toolchain]
build: Win32 with Cygwin
host: Win32 with MingW
target: Native Win32
run: XBox
[Telco toolchain]
build: Debian
host: Debian
target: Solaris Workstation
run: production embedded 12 CPU Solaris mainframe
[Simple Debian toolchain]
build: Debian Linux AMD64
host: Debian Linux AMD64
target: host
run: target
[Fun Debian toolchain]
build: Debian AMD64
host: Debian AMD64
target: Debian PPC64
run: MacOSX laptop
When the target and host are different architectures,
you will need a C++ toolkit with cross-compilation
support.
Because of the many possible configurations, it isn't
clear exactly how to structure the debian packaging
and configuration system. At present my own configuration
management is factored, but not properly.
'The usual' use of the package on Debian will have
build: Debian binary package building machines [Is that right?]
host: Client Debian Linux box with same architecture as build machine
target: host
run: host
To make matters more complex, there are some additional
'configuration' options.
Some platforms don't support dynamic linkage. The default
for the 'target' and 'run' platform is dynamic linkage,
but clearly that can't be used if not supported, and some
developers prefer static linkage anyhow. The actual
compilation and linkage can be mixed with arbitrary
C/C++ codes, so a developer may use the system at a low
level, replacing some components, and selecting certain
compilation and linkage options.
OK, so in general, we need to install:
* documentation -- on the host machine
* compiler -- on the host machine
* wrapper generator -- on the target/run machine
* run time static libraries -- on the target machine
* run time dynamic libraries -- on the run machine
* source and object files -- on the target/run machine
* driver executables -- on the run machine
* felix library -- on the host machine
* C headers -- on the target machine
In addition, there is a choice of Ocaml compilers
for the build machine: the native code compiler is
prefered because it generates faster executables,
but isn't available on all platforms. The bytecode
compiler runs on more platforms (and Ocaml 3.0.8.3
native code compiler doesn't generate a working
'flxg' for the AMD64 at the moment, so the bytecode
compiler has to be selected).
Well this is all hard to get right, and I'm a newbie
Debian maintainer (as well as the upstream author).
In particular I'm having some problems deciding where
to install
flx_run.cpp -- this is the standard driver source
flx_run_static.o -- compiled driver for static link
flx_run_dynamic.o -- compiled driver for dynamic link
libflx_rtl_dynamic.so -- run time dynamic link library
libflx_rtl_static.a -- run time static link library
Note for example that in theory the run time library goes
in an entirely different place for static and dynamic
linkage -- it is needed for static link on the target,
but for dynamic link on the run platform.
This distinction isn't just for complex tool chains.
Even on an out the box Debian platform, and end user
of a Felix program will need the shared library
in their LD_LIBRARY_PATH if they're running a dynamically
loaded program, but the developer will need the static
library at link time to make a static link version.
Should both go in /usr/lib? Or should the dynamic link
library go in /usr/lib and the static link library
in /usr/lib/felix/rtl? In the latter case where
do the C include files go?
This is only a sample problem. Another is: where do
examples go? Felix 'example' codes should be executable,
and currently, like Python, Felix writes into the directories
containing sources, but /usr/share/* .. should be read only.
[Yes, this is a bug in my system, it needs to be fixed, but
I need to make a Debian package too and that currently has
a higher priority]
--
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850
Download Felix here: http://felix.sf.net
Reply to: