org.eclipse.cdt.managedbuilder.makegen
Interface IManagedDependencyPreBuild

All Superinterfaces:
IManagedDependencyInfo
All Known Implementing Classes:
DefaultGCCDependencyCalculatorPreBuildCommands

public interface IManagedDependencyPreBuild
extends IManagedDependencyInfo

Since:
3.1 A Tool dependency calculator may implement this interface or IManagedDependencyCalculator or IManagedDependencyCommands. An object implementing the interface is returned from a call to IManagedDependencyGenerator2.getDependencySourceInfo. Discussion of Dependency Calculation: There are two major, and multiple minor, modes of dependency calculation supported by the MBS. The major modes are: 1. The build file generator invokes tool integrator provided methods that calculate all dependencies using whatever method the tool integrator wants. The build file generator then adds the dependencies to the build file using the appropriate build file syntax. See the IManagedDependencyCalculator interface for more information. 2. The build file generator and the tool-chain cooperate in creating and using separate "dependency" files. The build file generator calls the dependency calculator to get the dependency file names and to get commands that need to be added to the build file. In this case, dependency calculation is done at "build time", rather than at "build file generation time" as in mode #1. This currently supports the GNU concept of using .d files in GNU make. There are multiple ways that these separate dependency files can be created by the tool-chain and used by the builder. a. In some cases (e.g., Fortran 90 using modules) the dependency files must be created/updated prior to invoking the build of the project artifact (e.g., an application). In this case, the dependency generation step must occur separately before the main build. Use the IManagedDependencyPreBuild interface defined in this file for this mode. b. In other cases (e.g., C/C++) the dependency files can be created as a side effect of the main build. This implies that the up to date dependency files are not required for the current build, but for the next build. C/C++ builds can be treated in this manner as is described in the following link: http://sourceware.org/automake/automake.html#Dependency-Tracking-Evolution See the IManagedDependencyCommands interface for more information. Note for GNU make: these separate dependency files are "include"d by a main makefile. Make performs special processing on make files: "To this end, after reading in all makefiles, make will consider each as a goal target and attempt to update it. If a makefile has a rule which says how to update it (found either in that very makefile or in another one)..., it will be updated if necessary. After all makefiles have been checked, if any have actually been changed, make starts with a clean slate and reads all the makefiles over again." We can use this to ensure that the dependency files are up to date by adding rules to the make file for generating the dependency files. These rules are returned by the call to getDependencyCommands. However, this has a significant problem when we don�t want to build the build target, but only want to �clean� the configuration, for example. If we invoke make just to clean the configuration, make will still update the dependency files if necessary, thereby re-generating the dependency files only to immediately delete them. The workaround suggested by the make documentation is to check for an invocation using the �clean� target, and to not include the dependency files it that case. For example, ifneq ($(MAKECMDGOALS),clean) include $(DEPS) endif The restriction with this is that it only works if �clean� is the only target specified on the make command line. Therefore, the build "clean" step must be invoked separately.

Method Summary
 boolean areCommandsGeneric()
          Returns true if the command lines returned by this interface are not specific to the particular source file, but are only specific to, at most, the configuration and tool.
 java.lang.String getBuildStepName()
          Returns the name to be used in the build file to identify the separate build step.
 java.lang.String[] getDependencyCommands()
          Returns the command line(s) to be invoked in the separate dependencies pre-build step.
 org.eclipse.core.runtime.IPath[] getDependencyFiles()
          Returns the list of generated dependency files.
 
Methods inherited from interface org.eclipse.cdt.managedbuilder.makegen.IManagedDependencyInfo
getBuildContext, getSource, getTool, getTopBuildDirectory
 

Method Detail

getDependencyFiles

org.eclipse.core.runtime.IPath[] getDependencyFiles()
Returns the list of generated dependency files. The paths can be either relative to the top build directory, or absolute in the file system.

Returns:
IPath[]

getBuildStepName

java.lang.String getBuildStepName()
Returns the name to be used in the build file to identify the separate build step. Note that this name should be unique to the tool since multiple tools in a tool-chain may be using this method of dependency calculation.

Returns:
String

getDependencyCommands

java.lang.String[] getDependencyCommands()
Returns the command line(s) to be invoked in the separate dependencies pre-build step.

Returns:
String[]

areCommandsGeneric

boolean areCommandsGeneric()
Returns true if the command lines returned by this interface are not specific to the particular source file, but are only specific to, at most, the configuration and tool. If the build context is a resource configuration, this method should return false if any of the command lines are different than if the build context were the parent configuration. This can be used by the build file generator in helping to determine if a "pattern" (generic) rule can be used.

Returns:
boolean