beautypg.com

How nsdee adds rules to handle deleted headers – HP Integrity NonStop J-Series User Manual

Page 54

background image

In

Example 3 “Sample build rule for Door.o in subdir.mk”

, the remaining output from sed is written

to Debug/src/Door.d, the same directory Door.o is written to, and the dependency file path
is written to Debug/src/subdir.mk in the form:

CPP_DEPS += \
./src/Door.d

The top-level makefile includes such dependency files using this statement:

-include $(CPP_DEPS)

How NSDEE adds rules to handle deleted headers

By default, NSDEE makes a final adjustment to dependency files after they are generated by the
compiler and piped through grep and sed. These adjustments ensure that removing header files
does not result in build failures.

For example, if CarTest.o has these dependencies:

CarTest.o: ../src/Car.h
CarTest.o: ../../CarParts/src/Wheel.h
CarTest.o: ../../CarParts/src/Door.h
CarTest.o: ../../CarParts/src/Window.h
CarTest.o: ../../CarParts/src/Engine.h

and you remove the file Wheel.h, the next build of CarTest.o will fail because make will be
unable to locate Wheel.h. This is because dependency files are generated after object files are
built.

So NSDEE does a final pass over dependency files to address this issue by adding dummy rules
for header files that resolve to nothing. At the same time, NSDEE cleans up the list of object files.
The result on the above example would look like:

CarTest.o: ../src/Car.h ../../CarParts/src/Wheel.h ../../CarParts/src/Door.h \ ../../CarParts/src/Window.h
../../CarParts/src/Engine.h
../src/Car.h:
../../CarParts/src/Wheel.h:
../../CarParts/src/Door.h:
../../CarParts/src/Window.h:

../../CarParts/src/Engine.h:

NOTE:

If you invoke make outside of NSDEE, the updates NSDEE makes to dependency files

will not occur. This is not a problem unless you remove a header file. You can work around this
issue when doing builds outside of NSDEE by invoking make clean and then rebuilding, or by
editing out the dependencies on non-existent headers.

How SQL/MX preprocessor file header dependencies are handled

For SQL/MX preprocessor files (files ending with .ec, .eC, and so on), the SQL/MX preprocessor
generates an initial dependency file that replaces the source file extension with .dep This extension
differentiates SQL/MX header dependencies from C/C++ header dependencies, which are written
to files with the extension .d. By default, the SQL/MX preprocessor processes only SQL/MX-specific
header files using the .mxh extension, which is the model that NSDEE supports.

NSDEE directs the SQL/MX preprocessor to write the dependency file to the output directory by
specifying the -V option to the SQL/MX preprocessor invocation. However, the dependency file
generated by the SQL/MX preprocessor is not in a form the make program can parse. To format
the dependency file that make can parse, the build rule pipes the content of the file through a
series of sed commands to change original output. Where testmx.ec is a source file and
testmx.mxh

and testmx2.mxh are files included by testmx.ec:

C:\Users\doon\workspace\mxprog\src\testmx.ec
testmx.mxh
testmx2.mxh

The series of sed commands then transforms the SQL/MX dependency output to the following
form:

54

Concepts

This manual is related to the following products: