Inhalt
Topic:.CheckDeps_C.
.
Topic:.CheckDeps_C.problem.
Maker checks older/newer file. If older versions are used, no sensitive. Unix: copy produces newer file - resolve problems.
Maker syntax to complex (writeonly script)
Dependencies from all headers?
Building of Dependencies with a Compiler tool needs some time.
Topic:.CheckDeps_C.solution.
The tool CheckDeps_C evaluates C/C++-language files to check its timestamps and dependencies. It is written in Java: package srcJava_Zbnf:_org/vishia/checkDeps_C/package-summary. It is able to call as command line invocation from Windows batch-files or a Unix shell script or it is able to call especially in a script of Zmake.
Topic:.CheckDeps_C.solution.deps.
The tool srcJava_Zbnf:_org/vishia/checkDeps_C/CheckDependencyFile reads an input text file which contains from the last calling:
all source files inclusively its header files with its time stamp
all dependencies of each file
If such a list is not available because it is the first build or a build all invocation, the list can be missed. Then no timestamps and dependencies are known.
One after the another source file are processed with this class.
Either the time stamp of the source file is exact the same. Then the source file should be assumed as unchanged. In this case all of its primary dependencies are unchanged and known from this block in the dependency file. But the dependent files should be testet too. It is recursively.
Or the time stamp is changed, older or newer, then the source file may be changed. In this case all of its dependencies are invalid.
If the dependencies are invalid, the file is checked line per line. Each found #include statement is a dependency for the source file. All depending files are checked in the same way like the source file. It means,
a dependency-file may be unchanged because its time stamp is unchanged. Then the known dependencies are used as known for
the deeper level and they are checked, but the unchanged file is not processed.
The result of the dependency check is the new dependency situation, which are logged into the dependency file written as output.
If a file is changed or any of its dependency files are changed, the file should be translated (compiled) newly. If any headerfile is changed, but the source file is not changed, the source file should be translated anyway too. To force the translation, its object file or more files are deleted from the object directory.
The deleting of the object file(s) should be done immediately while the inconsitency was found. Because a next processing of the dependency and time-stamp check with the newly written dependency file would not found a changed file. Anytime the comparison between the last and the current situation will be assessed.
A standard maker (GNU, ANT) or a check of existence of the objectfile (in a shell or batch script) will be force the compilation because the object file is removed. If the object file was not removed and the source will be changed but older or any dependency is unkown in the maker script, the maker will not force the compilation. That will be faulty. The deleting of the object helps to educate the correct situation.
Topic:.CheckDeps_C.solution.checkContent.
It is the second approach of the CheckDeps_C tool. Some tools generate secondary source files though it is unnecessary. There content is not changed really, only some information written in comments for C-compilation are changed: Time stamp of generation, revision numbers, the person which is logged in in the computer etc. If all that files will be compilated it needs a lot of time.
The CheckDeps_C tool can work with mirrored sources. If the time stamp of a source is changed, it compares line per line with the mirror-source file. If only comment parts are changed, the associated object file is not deleted and the mirror-source is not renewed. A maker can work with the mirror source. Then it does not found a newly source and does not compile.
Topic:.CheckDeps_C.solution.sourcepool.
If the files are compiled with a make file which is generated from any tool, the source files are known in the makefile but the effort to control the CheckDeps_C to check one file after another is to high. Instead one or more directories which contains the source files are parametrized. The srcJava_Zbnf:_org/vishia/checkDeps_C/CheckDeps with possible start from command line checks all that source files.
Topic:.CheckDeps_C.solution..
System header file (stdio.h etc) are not checked because it should be assumed that they are unchanged. On the other hand the system headers may be more
complexely especially with conditional compilations (#if defined(...)) as the users file. Therefore it may be an effort to check them.
The control file set with srcJava_Zbnf:_org/vishia/checkDeps_C/CheckDependencyFile#readCfgData(java.lang.String) or the argument -cfg:file.cfg from docuSrcJava_Zbnf:_org/vishia/checkDeps_C/CheckDeps#main(java.lang.String[]) has the following syntax, example:
$SBOX_DIR=./. -s=$(SBOX_DIR):source -s=$(SBOX_DIR):sourceSpecials/os_Windows_Msc6 -i=$(SBOX_DIR):include -i=$(SBOX_DIR):include/OSAL -i=$(SBOX_DIR):includeSpecials/os_Windows_Msc6 -y=D:/Progs/MSC6/act/Microsoft Visual Studio/VC98/Include
which is more formalistic:
{$envVar=value}
{-s=[$(envVar):]sourcepath}
{-i=[$(envVar):]includepath }
{ -y=systemincludepath }
A local variable can be defined and used in the shown kind.
Files are searched in alldirectories designated with the -s=path. That is only by CheckDeps-start per command line.
Include files are searched by name in all pathes designated with -i=path or -y=path.
Files in the -y=path is accepted but not tested. They are the system includes.
Topic:.CheckDeps_C.solution..
If a user file contains
#ifdef DEFINE #include <something.h>
it is not regarded as a special case.
Topic:.CheckDeps_C..
The dependency file should not only used for internal storage of the depedency situation. It should be evaluated from the programmers too. Often some unfortunate includes forces unnecarry dependencies and lengthens the make times:
Project specific definitions may be assembled in one headerfile. It may be correct. This file may be included by many files, all of them depends of this.
Such a project file should be stable. Changes are done only if substantially project specifics are changed.
If this project file includes any special file, which may define a const value, and this file is changed frequently because other things than the constant value, it is a unfortunately dependency.
The dependency file should help to investigate whether a source file have to be compiled though the programmer is aware of no guilt. The programmer can detect which included file is to blame to force the compilation.
The next step may be: carefully change the include situation and the assignment of parts of sources to the header files. That is an important and difficult chapter of programming. If larger software projects are created with the same source pool, it is worthwile to improve that things.
The dependency file shows the following information:
#Special designation chars: # ^ Changed timestamp, but no content change outside comments in comparison with the mirror file. # & Recompile the file and all using files because an included file is changed. # $ Recompile like &, this file has a changed timestamp, but no content change outside comments too. # ! This file is changed, force recompile of all including files. #Include designation: # - Direct included. # + Indirect included in another included file. # * This file includes the named file directly. It depends on it. # % This file includes the named file indirectly. It depends on it. File: 2012-12-25 16:16:46; 1356448606000; D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_Exception.h .includes: !- D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_MemC.h - D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_String.h + D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/OSAL/os_types_def_common.h + D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/includeSpecials/os_Windows_Msc6/os_types_def.h .is included in: * D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_ThreadContext.h * D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/source/Fwc/fw_Exception.c * D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/source/Fwc/fw_ExceptionPrintStacktrace.c * D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/source/Fwc/fw_MemC.c * D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/source/Fwc/fw_formatter.c % D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Jc/ObjectJc.h % D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Jc/ReflectionJc.h % D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/source/Fwc/fw_threadContext.c % D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/source/OSAL/Reflection_OSAL.c File: 2011-03-06 23:20:34; 1299450034000; D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/source/Fwc/fw_Exception.c .includes: &- D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_Exception.h - D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_SimpleC.h &- D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_ThreadContext.h - D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/OSAL/os_error.h !+ D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_MemC.h + D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/Fwc/fw_String.h + D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/include/OSAL/os_types_def_common.h + D:/vishia/Java2C/sf/Java2C/CRuntimeJavalike/includeSpecials/os_Windows_Msc6/os_types_def.h .is included in:
It is a part of the file. In this example the headerfile f_MemC.h is changed. The character ! should be searched in the whole text. It shows the changed files. All depending files are found with them.
Any file can be searched in this text file of the dependencies. It is listed which files it includes and from which files it is included.