Working with BENV

BENV makes it easy to create and use a source file library, but due to the sheer number of potential source code libraries involved in any given project, it can be difficult to know what is needed for a new project.

This page is an attempt to document the process that I use when starting a new project.

  1. Copy an existing project that uses the best mix of existing high level components that are required by the project.
    1. Copy tools.b from a project from an identical or similar platform. If an exact platform is not availble, then the entries that are referenced in this file must be created. Variants include:
      1. hosttools - defines common shell tools required by BENV. For UNIX/Linux hosts, this is typically defined as $(HOST). Other platforms are more ... interesting.
      2. toolchain - defines  BENV variables that describe the names and locations of comilers linkers and other tools and options to build and link source code modules. New GCC cross compilers are relatively easy to port.
      3. targetos - defines symbols that specify include paths and libraries that are commonly linked with the final executable.
      4. linkfile -This is typically a very platform/debug environment specific makefile fragment that is used to link the final executable.
    2. Copy overrides.b from project from an identical or similar platform. If an exact platform is not availble, then various entries in overrides.b will need to be changed depending on the availability of reusable parts. Potential variables include
      1. tool chain (compiler, linker, etc.)
      2. standard libraries (glibc/newlib,libstdc++)
      3. CPU type
      4. Cache organization.
      5. User/Kernel space.
      6. Platform specifics described in linker scripts.
    3. Replace platform specific references from old project.
      1. libdirs.b - look for pathnames that contain names that refer to specifics that are not available on the new project's platform. Hardware specific references are most obvious.
      2. overrides.b - look for paths that reference platforms other than that of the new project. Other items that may vary are toolchain specific options, and references to linker options, object files and  and libraries.
    4. Remove un-desired modules specified in libdirs.b (if known).
    5. Remove/replace applicatin specific portions from the main() and other project specific source files copied from the original project. Less is better when a new platform is involved.
  2. Make it compile
    1. Remove/replace/create project and platform specific source libraries. If a module will not compile, then it should be inappropriate for your platform or platform copiler specific include paths in overrides.b are wrong or unimplemented.
  3. Make it link
    1. Resolve link time dependencies. These are indicated as "unresolved" symbols in the linker error output. This may involve:
      1. Adding the appropriate source library to libdirs.b .
        1. Look at the name of the unresolved symbol, which should give you clues as to the potential source of the symbol. The most common possible sources include
          1. Toolchain libraries (i.e. libgcc.a)
          2. Third party libraries.
          3. Linker-script defined symbols.
          4. source libraries.
  4. Add new source code components to the libdirs.b file.