]> rtime.felk.cvut.cz Git - frescor/frsh-forb.git/blobdiff - README
Fix Makefile to work with new OMK
[frescor/frsh-forb.git] / README
diff --git a/README b/README
index 68d2b820b4a23b4ecaf2ef93c05571f7c511a6f5..986058f09ce60a3518b6b23afddb77836963fee7 100644 (file)
--- a/README
+++ b/README
 
 * BUILDING FRSH/FORB FRAMEWORK
 
-1) Initialize and download additional submodules:
-   
-   git submodule init
-   git submodule update
-
-2) Install prerequisites. On Debian/Ubuntu:
+1) Install prerequisites. On Debian/Ubuntu:
 
      apt-get install libidl-dev libcpufreq-dev libacpi-dev \
                     libcgroup-dev libncurses5-dev
@@ -32,7 +27,7 @@
 
      apt-get install freeglut3-dev
 
-3) Go to build directory and configure the build:
+2) Go to build directory and configure the build:
    
    cd build/aquosa
    make default-config
    CONFIG_CPUCG=y >> config.omk). Note, that cgroups support is not
    well tested, but we plan to work on it.
 
-4) Compile it:
+3) Compile it:
 
    make
 
-5) Test it:
+4) Test it:
 
-   ./_compiled/bin/fcb &
-   ./_compiled/bin/frm_dummy &
-   ./_compiled/bin/frm_gui &
-   ./_compiled/bin-tests/dummy_renegotiation
+   make test
 
 * DIRECTORY STRUCTURE
 
   * src/fwp - Communication protocol and resource management for WiFi
     (also works with Ethernet).
 
-* OLD HOWTO - may be out of date
-
-    Linux + AQuoSA
-
-     * Install AQuoSA (http://aquosa.sourceforge.net)
-     * $HOME/frescor/src/omk-build/aquosa
-     * Adjust symlinks to FRESCOR modules (fosa, frsh, utils, ...) or use ./create-links script
-     * Create config.omk containing (or use a shell variable in your .bashrc)
-
-  AQUOSA_ROOT=/path/to/aquosa/install/path
-
-     * Actually, my preferred way of working is adding the following
-       variables in .bashrc:
-
-  # AQuoSA environment
-  export AQUOSA_ROOT=/usr/local/aquosa
-  export PATH="$PATH:$AQUOSA_ROOT/bin"
-  export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$AQUOSA_ROOT/lib"
-  # FRESCOR environment
-  export PLATFORM=AQuoSA
-  export FOSA_ROOT=$HOME/path/to/fosa
-  export FRSH_ROOT=$HOME/path/to/frsh
-  export UTILS_ROOT=$HOME/path/to/utils
-  LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$FOSA_ROOT/lib:$FRSH_ROOT/lib:$UTILS_ROOT/lib"
-  # OMK environment
-  # Use `omk' for OMK-enabled sources
-  alias omk="make -f $HOME/path/to/Makefile.rules"
-  # link headers instead of copying them
-  export LN_HEADERS=y
+* MISCELLANEOUS
 
-     * Create default-configuration by running
+** Advantages of OMK make system
 
-  make default-config
-
-     * Run
-
-  make
+     * It is not easy to test FRSH/FORB simultaneously on multiple
+       platforms. With OMK, you can have the same sources compiled for
+       multiple platforms/targets at the same time because it uses out
+       of source directory compilation.
+     * Automatic handling of dependencies. When a file is changed,
+       only the files dependent on it are rebuilt. Developers don't
+       have to care about this.
+     * With OMK it is easy to combine multiple components/libraries (from
+       different developers) together and compile them with the same
+       configuration (e.g. PLATFORM variable). The structure of leaf
+       makefiles (Makefile for every component) is very simple and *well
+       specified*. Because of this it is easy to combine components from
+       multiple developers.
+     * OMK already supports compilation for user-space
+       programs/libraries, Linux and RTLinux modules, RTEMS and
+       several other platforms. Now we have also added support for
+       Marte. OMK works under MinGW and Cygwin, so it can be used to
+       compile for OSE. In Pisa, they already use OMK for Aquosa.
 
 ** Further remarks
 
-- If we are not interested in compilation of some component (because
-  it is currently in uncompilable state), we can simply delete the
-  link to it.
+- If you are not interested in compilation of some component (e.g .
+  because it is currently in uncompilable state), you can simply
+  delete the link to it.
 
 - It might be possible that you will need to change some configuration
   value from config.target. You can override any variable declared
-  there in config.omk. For example, if you have MARTE installed in a
-  different directory that the one specified in config.target, you can
-  put the following in config.omk:
+  there in config.omk - just create it and put variable definitions to
+  it. For example, if you have MARTE installed in a different
+  directory that the one specified in config.target, you can put the
+  following in config.omk:
 
   MARTE_PATH=/path/to/marte/
 
-- To compile the FRESCOR for Marte, it is not necessary to set PATH
-  variable to GNAT compiler since OMK uses full paths to call the
-  compiler.
-
-- Since there are many things in uncompilable state, you may want to
-  use `make -k' to ignore compilation errors.
-
-- Since we don't want to modify the original Makefiles, in order to
-  compile only a part of the tree, you cannot simply run make in the
-  desired directory, but you have to specify -f flag with the path to
-  Makefile.rules. For this reason, we recommend defining the following
-  alias:
-
-  alias omk="make -f $HOME/frescor/src/omk-build/marte/Makefile.rules"
+- FRSH/FORB support for Marte OS is not maintained. However, if you
+  want to try it, it is not necessary to set PATH variable to GNAT
+  compiler since OMK uses full paths to call the compiler.
 
-** Why is OMK good for FRESCOR
-
-     * It is not easy to test FRESCOR simultaneously on multiple platforms.
-       With OMK, you can have the same sources compiled for multiple
-       platforms/targets at the same time because it uses out of source
-       directory compilation.
-     * Dependencies are not handled correctly in current Makefiles. For
-       example headers (in most tests) and some libraries (fosa_xxx) are not
-       specified as dependencies. OMK handles dependencies automatically, so
-       developers don't have to care about them.
-     * With OMK it is easy to combine multiple components/libraries (from
-       different developers) together and compile them with the same
-       configuration (e.g. PLATFORM variable). The structure of leaf
-       makefiles (Makefile for every component) is very simple and *well
-       specified*. Because of this it is easy to combine components from
-       multiple developers.
-     * Directory structure for compilation with current makefiles must be
-       fixed. In makefiles there is many "..". This prevents the use of
-       symbolic links to create desired directory structure because make
-       always treats ".." physically (i.e. it don't respect the directory
-       structure created by symbolic links). In OMK, the position of
-       directories in the source tree is not important. This is another
-       reason, why integration is simpler with OMK.
-     * OMK already supports compilation for user-space programs/libraries,
-       Linux and RTLinux modules, RTEMS and several other platforms. Now we
-       have also added support for Marte. It works under MinGW and Cygwin, so
-       it can be used to compile for OSE. In Pisa, they already use OMK for
-       Aquosa.
+- Since we don't want to modify the Makefiles developed for Marte OS,
+  in order to compile only a part of the tree, you cannot simply run
+  make in the desired directory, but you have to specify -f flag with
+  the path to Makefile.rules. For this reason, we recommend using omk
+  script instead of make. The script can be obtained from
+  http://rtime.felk.cvut.cz/gitweb/omk.git/blob_plain/HEAD:/omk.
 
 ** FAQ
 
 
    Just activate verbose compilation (V=1 or V=2):
 
+  make V=1
+
+  or
+
   make -f /path/to/Makefile.rules binary-pass V=1
 
 - How do I get back syntax highlighting in Emacs while editing .omk files ?