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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
