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
This page is an attempt to document the process that I use when
starting a new project.
- Copy an existing project that uses the best mix of existing high
level components that are required by the project.
- 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:
- hosttools - defines common shell tools required by BENV. For
UNIX/Linux hosts, this is typically defined as $(HOST). Other platforms
are more ... interesting.
- 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.
- targetos - defines symbols that specify include paths and
libraries that are commonly linked with the final executable.
- linkfile -This is typically a very platform/debug environment
specific makefile fragment that is used to link the final executable.
- 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
- tool chain (compiler, linker, etc.)
- standard libraries (glibc/newlib,libstdc++)
- CPU type
- Cache organization.
- User/Kernel space.
- Platform specifics described in linker scripts.
- Replace platform specific references from old project.
- 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.
- 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.
- Remove un-desired modules specified in libdirs.b (if known).
- 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.
- Make it compile
- 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.
- Make it link
- Resolve link time dependencies. These are indicated as
"unresolved" symbols in the linker error output. This may involve:
- Adding the appropriate source library to libdirs.b .
- 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
- Toolchain libraries (i.e. libgcc.a)
- Third party libraries.
- Linker-script defined symbols.
- source libraries.
- Add new source code components to the libdirs.b file.