TargetSpecifications.hpp File Reference

Precise definitions of the targets for the build-system. More...

Go to the source code of this file.

Detailed Description

Precise definitions of the targets for the build-system.

See Buildsystem/OKlibBuilding/plans/general.hpp for overall todos.

General look and feel
  • The directory structure is "recursive", names with capital first letters for (sub-)modules, while "systematic directories" have all small letters.
  • Yet we can call for example "make -f Path/makefile all" from anywhere, and it will have always the same effect (that is the role of variable srcdir) --- will this be automatically achieved with the makefiles created by cmake? DONE (with the masterscript oklib we get full control over the effect of the calling place)
New target for main action
  • Yet very often "oklib all check new_check app_tests html" is called.
  • The should be a super-target for that; how to call it? "update" ??
  • Perhaps "build_test_docu".
  • Perhaps better "buildtestdocu": shorter to write, and we use such names for targets in general.
  • Then however the order of processing is changed, due to the recursive makefiles: in every part all of "all check new_check app_tests html" is performed, before going to another part!
  • Yet, we can not express dependencies directly, but they are somehow handled by the global order; now there could be interferences?
  • Likely "check" and/or "new_check" needs "all" to be completed?
  • So perhaps this new target is only to be used in "non-critical" contexts?
  • So perhaps we postpone the introduction of this new target, until we have a better grasp on the dependency problems.
  • Compare "Test system" in Buildsystem/OKlibBuilding/plans/general.hpp for a similar problem; don't we have a global todo regarding the consideration of all dependencies?
Target "all":
  • Prerequisites: targets "apps", "demos", "exp" (for experiments).
  • Let Dir be the directory where the master-make-script is present:
    1. All .cpp-files below Dir in directories
      1. apps
      2. demos
      3. exp
      must be programs and are compiled (respectively for the sub-targets).
    2. The generated programs go to bin/Dir/path, where path is the relative path in Dir to the .cpp-file.
    3. Perhaps bin has subdirectories apps, demos, exp, and inside we put the binaries to Dir/path', where path' has been cleaned resp. from "apps", "demos", "exp". ?! Looks better.
    4. The .o-files are not of importance here.
  • Similar for .c-files.
  • Customisation of compiler and linker options:
    1. The link-libraries for a .cpp-file with main() are collected from the link-libraries of the .cpp-files linked to it, and from the link-library-file for this .cpp-file itself.
    2. The (recursive) make-variable source_libraries is kept, predefined as "$(OKSystem_include) $(Boost_include)" (potentially changed in the locale definitions-makefile): If file .source_libraries exists, then it overrides "$(source_libraries)".
    3. Every .cpp-file has a .source_libraries file (if needed).
    4. We need to customise naming of generated executables, by a new make-variable which allows to override the current (automatic) setting of the -o-option.
    5. More precisely, when compiling "programs" then there need to be two versions of the action, one with "-o $@" as now, one using "-o $(program_name_okl)" resp. "-o $(program_name_optimised_okl)".
    6. Or can this be done by simply using "-o" a second time, re-defining the name? The question here is whether the first or the second usage of "-o" is decisive.
    7. DONE : Every .cpp-file has a .link_libraries and .link_libraries_optimised file (if needed), and a .compiler_options and a .compiler_options_optimised file (if needed).
  • What to do with the unoptimised and the optimised versions?
    1. The names of the created .o-files and executables should reflect "all" compiler options.
    2. There are generic links to the unoptimised and the optimised version.
  • What to do if we create link-libraries in the OKlibrary? Perhaps this should go into another systematic subdirectory, say, "libraries" ? The created libraries then go to lib/Dir/path'. where path' has been cleaned from "libraries".
  • For every created "file.o" and "file" we have the "file.compilation_log" (in the same directory where these files go). Optionally we can switch it off.
  • There is a make-variable for optional name extensions.
Target "check"
  • Compiles and runs all tests (unoptimised and optimised).
  • The tests are exactly those in directories "testobjects" (which contain only .cpp-files (without main())).
  • With "check" all new .o-files are created, and the new (single) test-executable only links these new .o-files together. Optionally we can also link all .o-files together (new and old ones). Of course, if we create a test for the whole library, then the executable will be big, but that's how it is. Since we have dynamic test-circumstances (different testobject-files linked together), which might, due to global dependencies, influence the test-outcome, we need logging of the precise compilation-process.
  • The test-programs go to subdirectories in bin/tests, reflecting appropriately the source-directory structure.
  • Subtargets "test" and "testop" for compiling and running the unoptimised resp. optimised tests.
  • For just compiling the tests there are subtargets "test_compile" and "testop_compile" (combined "check_compile").
  • For just running the tests there are subtargets "test_run" and "testop_run" (combined "check_run"). For cleaning the tags here we have "clean_test_run" and "clean_testop_run" (combined "clean_check_run").
  • It seems we should create a special target "valgrind-check" where the files are especially compiled for Valgrind --- this seems to be needed to do automatic checks.
    1. valgrind has a (new) flag "--error-exitcode=", by which we should be able to get an error making the build-process stop in case valgrind finds an error. So perhaps special compilation is not needed?
    2. We should use "gcov" from time to time (supported by the build system) to check whether at least all lines of code are covered by the tests.
Target "prebuild"
  • Creating symbolic links (for the master-makefile-script), some directories, and all preparations which are needed to get the build-system running at all. Needed when installing the system.
Target "html"
  • See "Definitions for doxygen" in Buildsystem/plans/Configuration.hpp for the dependency on the doxyfile.
Target "app_tests"
DONE (likely not needed, since at least for now we don't use cmake) Target "reset"
  • This target is handled by the master-script, and it reruns cmake (while all other targets are passed to the created make-files --- this assumes, that cmake was run at least once, so perhaps reset is also part of "prebuild" ??).
Target "new-module"
  • Creates a new module (with the appropriate sub-directories, links, etc.), and runs "reset".

Definition in file TargetSpecifications.hpp.