general.hpp File Reference

Plans for the buildsystem in general. More...

Go to the source code of this file.

Detailed Description

Plans for the buildsystem in general.

Evaluation mode for oklib
  • In the plans, one places shell commands referencing locations given by make variables. This is especially true when discussing new external sources.
  • For example, see "Minion" in Buildsystem/ExternalSources/SpecialBuilds/plans/CSP.hpp .
  • These commands can not be run directly in a shell. The make variables must be replaced by hand.
  • We should have a "--evaluate" option for oklib. This option would evaluate the command given to it in the context of the BuildSystem environment.
Making make-variables compatible with shell-variables:
  • To avoid problems, we should use C(++) naming conventions for make-variables, which means that in all make-variables a hyphen "-" is replaced by an underscore "_" (being careful not to introduce ambiguities).
Further renamings:
  • Buildsystem/recursive_noneincluded.mak -> Buildsystem/Recursive_noneincluded.mak (perhaps also name should change)
  • Buildsystem/standardgoals.mak -> Buildsystem/Standardgoals.mak
System documentation
  • Document the basic version-control settings (location of server, configuration, how to use it).
  • Document the build-system (general ideas, functionality).
Renaming module Buildsystem
  • To be consistent with the other module names, it should be called "BuildSystem".
  • And we should move the module to part System.
  • But perhaps we leave it as it is --- it is a rather special system?
Documentation (Examples and Concepts) OK : this needs to be discussed and updated
  • At OKplatform-level we have a new directory Documentation, with the following sub-directories:
    1. Examples : contains a mirror of the OKlibrary with (many) example applications (build by the build system, so that it's always up-to-date).
    2. Concepts : contains for each module a latex-file discussing the concepts for this module.
Modes of Usage
  • Two modes of usage of the build system:
    1. As we have it now, everything in one directory (and also with the possibility of having different versions of the OKplatform). ("One world", extending directly the library.)
    2. Having one global OKplatform, and then a local directory with also aux, bin, doc, include and lib, but only regarding the local directory. So that for example students in the Linux lab can use a central installation of OKplatform, and in the local directory only the files related to their production is stored.
  • This should go, and makefile_generic should be able to do all jobs, gathering all relevant files from all underlying subdirectories (but as soon as one subdirectory doesn't contain makefile_generic, then it and its descendants are ignored).
  • It seems important that for example every subdirectory of a module can itself contain tests- and testobjects-subdirectories.
  • The directory-tree in system_directories must mirror the primary directory-tree.
Source code directory structure
  • We need a rational system for the naming of header files. We should study the Boost library here.
  • The namespace should be the directory part of the name for the OKlib (for example OKlib::Algorithms is the file OKlib/Algorithms).
  • Directory OKsystem/OKlibrary should then be called OKsystem/OKlib.
  • As proposed in [C++ Templates], we should also provide files per module only containing declarations (perhaps parallel to each .hpp file). Ending "_decl" ?
  • Module.hpp provides all includes, Module_decl.hpp all declarational includes.
  • Perhaps special naming conventions for files with messages or exceptions ?! DONE --- we use sub-directories like "messages" instead of systematic name-extensions. Whether we also use sub-directories "exceptions" needs to be seen.
  • Should we use <> or "" for includes from our library? DONE --- always use the "system header" form with angle brackets!
Full test
  • makefile at the OKplatform level --- there the different versions of gcc and boost are visible.
  • "make check" at this level should run through all appropriate combinations of gcc and libraries and test them.
Integration testing:
  • We need some file format (likely some xml) to specify one integration test:
    1. Specify the input file. (Possibly more input files.)
    2. Specify the program to be run with this file as input.
    3. Specify the command-line options for running the program.
    4. Specify the output-check (perhaps a regular expression?).
  • Then we need a way to execute such integration tests and to report errors.
  • Could we use the unit-testing framework here? Likely not.
Compiler versions
  • Do we get slower run-times with g++ 4.1.2 compared to 4.1.1, and thus we need to write no-throw-declarations? (Perhaps this needs to be done anyway?)
Version numbers
  • It would be good to have not only version numbers for modules, but also for single files (to indicate the state of development) ?!

Definition in file general.hpp.