This documentation is no longer maintained and may contain obsolete information. You should instead refer to Application onboarding.
On this page:
Verify the source code type
Although source code type is detected by the DMT during the delivery, it is recommended to confirm this setting at Analysis Unit level.
This has an impact on how the files are analyzed. For example, if you choose an analysis of type C, function comparison will be done on the function name only as C does not allow overloading. However, if you choose C++, the comparison will be done on the signature of the function (including parameters).
In cases where some source files contain source code that does not correspond to the extension (e.g.: "main.c" contains C++ code), then it is possible to force the language for this file. If unsure select Both C and C++.
Define analysis settings in the Analysis Unit
Normally, the source code discoverer will configure the Analysis Unit and analysis settings. However, in some circumstances, these settings may be incorrect and must be adjusted manually. The main parameters to work on are as follows:
- IDE used for the Analysis Unit
- STL Support
- Include paths
- Macro definitions
- Precompiled header
- Environment Profile
These are all located in the Analysis Unit editor:
IDE used for this Analysis Unit
This option allows to select the compiler, the version of the compiler, and the type of project that is build from the source code. It is automatically set up for MS Visual C++, thanks to vcproj and vcxproj project files. For other projects, it is generally necessary to adjust it.
STL Support
This option allows you to choose how you want CAST AIP to handle STL header files that are referenced in your source code. Not all other Environment Profiles provided by CAST AIP contain STL header files (for copyright reasons) and this can lead to an incomplete analysis, and thus to incomplete results. As a direct result of this, CAST AIP has introduced this option that allows you to tell the CAST Management Studio whether the STL header files are available or not.
Select the include paths
The include paths are locations from where the included headers are found. These parameters should be identified from the compilation directives. The files found in these include paths will be saved in the Analysis Service. Thus, the only header paths you should mention here are:
- the header path of the customer applications
You should not reference here any third party software header paths (see previous section). Also files that are common to several jobs should be defined in an Environment Profile. Note that include paths defined directly in the job are searched first. Include paths defined in Environment Profiles have a lesser priority. As for the compiler, inclusions defined within "" are searched within the path of the file being analyzed, while inclusions defined within <> aren't.
You should also avoid adding more include paths than required: the search for an included file in the include path list occurs regularly and too many unnecessary paths will affect performance.
Defining include paths for Microsoft compilers
Usually, if the Microsoft C++ compiler is installed on the analysis machine, you just need to select the default "Microsoft VCxxxx" environment profile (via the IDE used for this Application (or Analysis Unit) option). In some cases, you may also need to provide your include list yourself. The following rules should be followed:
- Do not add more directories then required (as mentioned above)
- Do not select the "recursive" option for these paths (as mentioned above)
- Do not select a path such as C:\Program Files\Microsoft Visual Studio 10.0\VC\crt\src (this typically contains files that are reserved for Microsoft internal use and debugger)
In any of the three cases above, you will get an error message during the analysis such as:
#error directive encountered 'Use of C runtime library internal header file ... (file 'C:\PROGRAM FILES\MICROSOFT[...]\VC\CRT\SRC\CRTDEFS.H")'
Include paths for Microsoft compilers should resemble the following:
For Microsoft VC++ 2008 and higher:
- C:\Program Files\Microsoft Visual Studio 10.0\VC\include
- C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include
- C:\Program Files\Microsoft SDKs\Windows\vxx.xx\include
(the third one is for <windows.h> etc., the exact value for xx.xx depends on your exact installation)
For older compilers:
- C:\Program Files\Microsoft Visual Studio 8\VC\include
- C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include
- C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDKinclude
For even older MS Dev 6 (VC98):
- C:\Program Files\Microsoft Visual Studio\VC98\Include
- C:\Program Files\Microsoft Visual Studio\VC98\MFC\Include
- C:\Program Files\Microsoft Visual Studio\VC98\atl\Include
External Functions
The "Force inclusion file" option is used to provide an extra header file which will be appended at the beginning of the preprocessed source, as if each source file were beginning with a #include directive on this file. It is useful in the following cases:
- When you have a very large number of macros
- When you have macros that need to be undefined (the GUI here can only define them)
- When the code is using embedded 'C' on Sybase: contrary to Oracle, the Sybase embedded 'C' preprocessor adds some code at the beginning of the generated files. To compensate for this behaviour, you should add the following code in the header used for this option:
- #include <sybhesql.h>
SQLCA sqlca;
- #include <sybhesql.h>
You should indicate here the "ExternFunctions.h". If you have several files to "force include", all you need to do is to create an additional file that will include them (using the #include directive) and set this file as being "force included".
Macro and advanced definitions
The macro definition should contain all the implicit and explicit macros used to compile the application. The implicit macros depend on the Operating System and compiler used.
Precompiled header
If the project contains a precompiled header, then the related settings can be specified in this section.
Environment Profiles
The goal of an Environment Profile is to provide ready-to-use configuration linked to the third party software (system and non-system libraries, frameworks, ...). When the compilation, interpretation, or execution environment of an application is based on this type of third party software, you should add the Environment Profile that corresponds to the third party software, so that the only remaining input in the Analysis Unit is specific to the source code to analyze.
Environment Profiles should be used as often as possible to accelerate the implementation. Some Environment Profiles are delivered by CAST (often named as "default profiles"), and you should use them to benefit from CAST's expertise and maintenance. You can also create your own profile for situations where code you have to analyze relies on third party software that CAST does not cover and that you may meet again in the future.
Selecting Environment Profiles
You must select the Environment Profile that match your development environment and the type of application. For example, on Linux, you would select the Linux environment. With Visual C++, you would select the profiles that match your version and the type of application. As the Environment Profiles might refer to locations not delivered by CAST AIP (like Visual C++), you must ensure that the requested product is installed.
Creating your own Environment Profiles
The custom Environment Profiles should contain the include paths and macros that are required in the jobs to handle third party software. If you have to create you own Environment Profiles, try to use macros (based on environment variables, registry keys, …) in the paths (e.g: include paths) whenever possible, so that those paths are dependent on the configuration of the analysis machine.
Source code inspection
During source code delivery acceptance phase (see Validate and Accept the Delivery) some inspections are performed to ensure all headers required to compile C/C++ projects are included as apart of the delivery.
The best way to do this is as follows:
- Make sure each project is in a separate Analysis Unit to avoid naming conflicts
- Make use of the Test Analysis feature to scan the source code. This will allow you to detect missing header files and macro definitions.
- Inspect the generated report showing pre-processing and parsing issues and resolve any problems that are still present - refer to C and Cpp - Troubleshooting for help and suggestions on how to resolve the most common situations.
Most common problems are related to missing header files. Only solution is to go back to the application team and reject the delivery requesting the missing header files.