Commit ff876cee authored by balaskoa's avatar balaskoa
Browse files

C++ cahged to {cpp} in asciidoc files


Signed-off-by: default avatarbalaskoa <Jeno.Balasko@ericsson.com>
parent 2aa75005
......@@ -265,7 +265,7 @@ image::images/4_F42.png[title="TITAN Flags"]
+
On the TITAN flags page, it is possible to specify the flags TITAN should be called with when compiling the TTCN-3 and ASN.1 files.
+
The options will be applied to the *COMPILER_FLAGS* macro. By default only the *Include source line info in C++ code* and *add source line info for logging* options are set.
The options will be applied to the *COMPILER_FLAGS* macro. By default only the *Include source line info in {cpp} code* and *add source line info for logging* options are set.
+
NOTE: The flag responsible for function or load test runtime generation is not set here, but on the Makefile creation attributes (as that flag is handled by the Eclipse external `makefile` generator too).
+
......@@ -275,13 +275,13 @@ For more information on the meanings of these options please refer to section 5.
+
image::images/4_F43.png[title="Preprocessor"]
+
The Preprocessor page only functions as reminder to the fact, that the generated `Makefile` uses the same tool for pre-processing the .ttcnpp, .ttcnin and C/C++ files.
The Preprocessor page only functions as reminder to the fact, that the generated `Makefile` uses the same tool for pre-processing the .ttcnpp, .ttcnin and C/{cpp} files.
. Preprocessor Symbols
+
image::images/4_F44.png[title="Preprocessor symbols"]
+
On the preprocessor symbols page, it is possible to specify the list of symbols that should be defined and the list of symbols that should be undefined when the C/C++ pre-processor tool is executed.
On the preprocessor symbols page, it is possible to specify the list of symbols that should be defined and the list of symbols that should be undefined when the C/{cpp} pre-processor tool is executed.
+
These lists of options are applied to the *CPPFLAGS* macro.By default both lists are empty.
+
......@@ -291,35 +291,35 @@ NOTE: There are a few symbols that are not displayed here, but are generated int
+
image::images/4_F45.png[title="Preprocessor include directories"]
+
On the included directories page, it is possible to specify the list of directories where the C/C++ pre-processor can look for included files.
On the included directories page, it is possible to specify the list of directories where the C/{cpp} pre-processor can look for included files.
+
The list of options is applied to the *CPPFLAGS* macro. By default the list is empty.
+
NOTE: Some directories (like the include directory of TITAN) are not displayed here, but are generated into the `Makefile`. They are required for proper operation.
. C/C++ Compiler
. C/{cpp} Compiler
+
image::images/4_F46.png[title="C/C++ compiler"]
image::images/4_F46.png[title="C/{cpp} compiler"]
+
A C/C\++ compiler tool used to process the generated and the user provided C/C++ files can be specified on the C/C++ compiler page.
A C/C\++ compiler tool used to process the generated and the user provided C/{cpp} files can be specified on the C/{cpp} compiler page.
+
This will be applied to the *CXX* macro. By default it is set to be: *g++*
. C/C++ Compiler Optimization
. C/{cpp} Compiler Optimization
+
image::images/4_F47.png[title="C/C++ compiler optimization"]
image::images/4_F47.png[title="C/{cpp} compiler optimization"]
+
The C/C++ compiler optimization page allows the specification of optimization options for C/C+\+ compiler.
The C/{cpp} compiler optimization page allows the specification of optimization options for C/{cpp} compiler.
+
The optimization level option can be: none, minor optimizations, common optimizations, optimize for speed, optimize for size. By default it is set to: common optimizations.
+
The other optimization flags option allows the specification of any user defined optimization flag that is supported by the C/C++ compiler.
The other optimization flags option allows the specification of any user defined optimization flag that is supported by the C/{cpp} compiler.
+
Both options will be applied the *CXXFLAGS* macro.
+
NOTE: The *–Wall* option is not displayed here, but is generated into the `Makefile`. It is required for proper operation.
+
For more information on the optimization flags please refer to the documentation of your C/C+\+ compiler. In case of the default C/C+\+ compiler *g++* is the manual pages of *g++* (invoked with the *man g++* command line command).
For more information on the optimization flags please refer to the documentation of your C/{cpp} compiler. In case of the default C/{cpp} compiler *g++* is the manual pages of *g++* (invoked with the *man g++* command line command).
. Platform Specific Libraries
+
......@@ -335,7 +335,7 @@ NOTE: Some libraries are not displayed here, but are generated into the `Makefil
+
image::images/4_F49.png[title="Figure"]
+
The Linker page only functions as reminder to the fact, that the generated `Makefile` uses the same tool for compiling C/C++ sources and linking the generated object files.
The Linker page only functions as reminder to the fact, that the generated `Makefile` uses the same tool for compiling C/{cpp} sources and linking the generated object files.
. Linker Libraries
+
......
......@@ -43,9 +43,9 @@ it is possible to refer to a whole project, instead of referring to files or fil
In Eclipse the fundamental difference to all previous systems is that in this case Eclipse as the platform provides all of the options for structuring the projects. Our IDE only extends the platform with TTCN-3 related features (and doesn’t define the whole platform).
On one side this is a limitation, on the other side this means, that anyone can extend his projects with additional capabilities, either by developing his Eclipse extensions (for example a builder that converts some 3rd party file format into TTCN-3 files), or by using existing 3rd party tools (for example CDT for working with C/C++ and Makefiles, JDT for Java, documentation supporting tools, supporting writing command line scripts easier … and the list goes on).
On one side this is a limitation, on the other side this means, that anyone can extend his projects with additional capabilities, either by developing his Eclipse extensions (for example a builder that converts some 3rd party file format into TTCN-3 files), or by using existing 3rd party tools (for example CDT for working with C/{cpp} and Makefiles, JDT for Java, documentation supporting tools, supporting writing command line scripts easier … and the list goes on).
The following ways of structuring are provided by Eclipse footnote:[There is one more dimension of structuring in Eclipse when several plug-ins are used on the same project /_by default all plug-ins are active on all projects _/.If there are several plug-ins active in/on a given project, this can create several ``layers'' of responsibilities. This is an important feature, as this makes it possible to mix plug-ins that each provide some separate functionality into a working environment that best supports the user’s daily work routine. For example on a parallel cooperation the Designer supports editing TTCN-3, ASN.1 and configuration files, while CDT support editing C/C++ and Makefiles practically covering all aspects of working with TITAN by default. For an example of sequential cooperation we can say, that the working directory we use to output the final product of TITAN (the executable test system), can be viewed by CDT as the source of information for debugging/profiling the generated executable.]:
The following ways of structuring are provided by Eclipse footnote:[There is one more dimension of structuring in Eclipse when several plug-ins are used on the same project /_by default all plug-ins are active on all projects _/.If there are several plug-ins active in/on a given project, this can create several ``layers'' of responsibilities. This is an important feature, as this makes it possible to mix plug-ins that each provide some separate functionality into a working environment that best supports the user’s daily work routine. For example on a parallel cooperation the Designer supports editing TTCN-3, ASN.1 and configuration files, while CDT support editing C/{cpp} and Makefiles practically covering all aspects of working with TITAN by default. For an example of sequential cooperation we can say, that the working directory we use to output the final product of TITAN (the executable test system), can be viewed by CDT as the source of information for debugging/profiling the generated executable.]:
* Each file and folder below the project’s folder is part of the project, and by default should be used to operate the project. However, plug-ins working on the project can choose to ignore some of them on their own. For folders this is very much like file groups in mctr_gui, but in this case all files/folders in a given folder are part of that project by default.
......
......@@ -52,17 +52,17 @@ This step, if needed, is carried out manually by the user.
=== Module Compilation
In this step C++ files are generated from virgin TTCN-3 and ASN.1 files. When a C++ file already exists, then the timestamp of the Compile file is used to decide whether a C++ file in question is uptodate or not. A C++ file is refreshed only if the corresponding TTCN–3 or ASN.1 module was modified later than the timestamp in the Compile file indicates, or the project was refreshed by *right clicking* the project and selecting *Refresh*; otherwise the generated C++ file is considered uptodate.
In this step {cpp} files are generated from virgin TTCN-3 and ASN.1 files. When a {cpp} file already exists, then the timestamp of the Compile file is used to decide whether a {cpp} file in question is uptodate or not. A {cpp} file is refreshed only if the corresponding TTCN–3 or ASN.1 module was modified later than the timestamp in the Compile file indicates, or the project was refreshed by *right clicking* the project and selecting *Refresh*; otherwise the generated {cpp} file is considered uptodate.
The first compilation of the modules will result in addition of the following files in the working directory:
* C/C++ header files:
* C/{cpp} header files:
+
These are the header files of the generated C++ code. One `.hh` file is generated for every TTCN–3 and ASN.1 module in the project with the same name.
These are the header files of the generated {cpp} code. One `.hh` file is generated for every TTCN–3 and ASN.1 module in the project with the same name.
* C/C++ source files:
* C/{cpp} source files:
+
These are the body files of the generated C++ code. One `.cc` file is generated for every TTCN–3 and ASN.1 module in the project with the same name.
These are the body files of the generated {cpp} code. One `.cc` file is generated for every TTCN–3 and ASN.1 module in the project with the same name.
* Compile file:
+
......@@ -77,7 +77,7 @@ Module compilation is done automatically by the build process; no user action is
[[creating-dependencies]]
=== Creating Dependencies
Once the symbolic links have been created and the `Makefile` of the project has been properly edited if necessary, the command make dep has to be issued to find the dependencies between the resulting C++ codes. It is extremely important that the dependencies are always uptodate. If, for example, a TTCN–3 module is removed from the project, the dependencies between the C++ files must be updated, otherwise the command `make` fails.
Once the symbolic links have been created and the `Makefile` of the project has been properly edited if necessary, the command make dep has to be issued to find the dependencies between the resulting {cpp} codes. It is extremely important that the dependencies are always uptodate. If, for example, a TTCN–3 module is removed from the project, the dependencies between the {cpp} files must be updated, otherwise the command `make` fails.
Dependencies appear at the end of the `Makefile` as dependency lines. They are determining the conditions of the binary object code recompilation launched by the command make.
......@@ -92,7 +92,7 @@ Alternatively, incremental generation of dependency information is available whe
[[building]]
=== Building
In the final step of the project building procedure a conventional C++ compiler is used to compile Test port codes and the generated C++ source code to a binary object code. The resulting code is linked with the Base Library. The Base Library contains important supplementary function libraries used for the execution of the generated code (for example verdict handling, Host Controller code, and so on).
In the final step of the project building procedure a conventional {cpp} compiler is used to compile Test port codes and the generated {cpp} source code to a binary object code. The resulting code is linked with the Base Library. The Base Library contains important supplementary function libraries used for the execution of the generated code (for example verdict handling, Host Controller code, and so on).
If automatic building is enabled, Eclipse will invoke the build process whenever project resources change (are created, deleted or updated), or you refresh your project by *right clicking* the project and selecting *Refresh*.
......@@ -102,11 +102,11 @@ The build process will result in the generation of the following files in the wo
* Object files:
+
For every C++ file in the project (source code files, test ports, and so on), an object file (with the extension `.o`) will be created by the C++ compiler.
For every {cpp} file in the project (source code files, test ports, and so on), an object file (with the extension `.o`) will be created by the {cpp} compiler.
* Shared object files (if dynamic linking is enabled, see <<4-managing_projects.adoc#setting-the-local-build-properties-of-a-project, here>>):
+
For every (static) object file (with extension `.o`) in the project a shared object file (with the extension `.so`) will be created by the C++ compiler.
For every (static) object file (with extension `.o`) in the project a shared object file (with the extension `.so`) will be created by the {cpp} compiler.
* Executable:
+
......@@ -118,21 +118,21 @@ The build process can be configured to set the build level for the given project
+
Only syntactic and semantic checks are carried out on the TTCN-3 and ASN.1 source files.Uses the Makefile target *check*.
* Level 1 – TTCN3 → C++ compilation
* Level 1 – TTCN3 → {cpp} compilation
+
In addition to the syntactic and semantic checks, the C++ code is also generated from the TTCN-3 and ASN.1 source files if there were no errors found.Uses the `Makefile` target *compile*.
In addition to the syntactic and semantic checks, the {cpp} code is also generated from the TTCN-3 and ASN.1 source files if there were no errors found.Uses the `Makefile` target *compile*.
* Level 2 – Creating object files
+
Executes the syntactic and semantic checks, generates the C++ code and tries to compile it into object (`.o`) and if applicable, into shared object (`.so`) files.Uses the `Makefile` target *objects* or *shared_objects*.
Executes the syntactic and semantic checks, generates the {cpp} code and tries to compile it into object (`.o`) and if applicable, into shared object (`.so`) files.Uses the `Makefile` target *objects* or *shared_objects*.
* Level 2.5 – Creating object files with heuristic dependency update
+
Executes the syntactic and semantic checks and generates the C++ code, but before generating the object and if applicable, shared object files it also updates the dependencies of the source codes if this is needed. This means that the long lasting dependency refresh will not be executed if only such files that the on-the-fly analyzer is able to analyze were changed since the last build, and none of the changes made make a dependency refresh mandatory. Uses the `Makefile` targets *objects* or *shared_objects*; or *dep objects* or *dep shared_objects*.
Executes the syntactic and semantic checks and generates the {cpp} code, but before generating the object and if applicable, shared object files it also updates the dependencies of the source codes if this is needed. This means that the long lasting dependency refresh will not be executed if only such files that the on-the-fly analyzer is able to analyze were changed since the last build, and none of the changes made make a dependency refresh mandatory. Uses the `Makefile` targets *objects* or *shared_objects*; or *dep objects* or *dep shared_objects*.
* Level 3 – Creating object files with dependency update
+
Executes the syntactic and semantic checks and generates the C++ code, but before generating the object and if applicable, shared object files it also always updates the dependencies of the source codes. Uses the `Makefile` targets *dep objects* or *dep shared_objects*.
Executes the syntactic and semantic checks and generates the {cpp} code, but before generating the object and if applicable, shared object files it also always updates the dependencies of the source codes. Uses the `Makefile` targets *dep objects* or *dep shared_objects*.
* Level 4 – Creating Executable Test Suite
+
......@@ -272,7 +272,7 @@ The following files will be deleted from the working directory:
* All object files (files with suffix `.o`) and if applicable, all TITAN generated shared object files (files with suffix `.so`)
* All C++ sources files translated from the original TTCN–3 and or ASN.1 modules
* All {cpp} sources files translated from the original TTCN–3 and or ASN.1 modules
* The Compile file
......
......@@ -12,7 +12,7 @@ The TITAN Executor can operate in single or parallel mode.
* The parallel mode offers full-featured test execution including distributed and parallel execution. The goal of introducing the single operating mode was to eliminate redundancies concerning parallelism, and thereby increase the speed of execution.
It is possible to execute non-parallel test suites in parallel mode, but doing so results in unnecessary overhead. The C++ code generated by the compiler is suitable for both execution modes, there are no command line switches to select mode. The only difference is that another Base Library has to be linked in single and another in parallel mode.
It is possible to execute non-parallel test suites in parallel mode, but doing so results in unnecessary overhead. The {cpp} code generated by the compiler is suitable for both execution modes, there are no command line switches to select mode. The only difference is that another Base Library has to be linked in single and another in parallel mode.
The TITAN Executor plug-in is built on the TITAN Executor and provides support for the following launch and execution modes:
......@@ -32,7 +32,7 @@ NOTE: Execution in JNI mode is not supported on Windows
* The plug-in does not provide any means for the user to execute shell commands in the shell where the execution is happening.
* As the plug-in is directly interfacing with the C/C++ code in the main controller, it is dependent on the version and the platform of main controller.
* As the plug-in is directly interfacing with the C/{cpp} code in the main controller, it is dependent on the version and the platform of main controller.
Note that some execution modes require a properly set up runtime configuration file.
......
......@@ -109,7 +109,7 @@ For detailed information on installing the TITAN TTCN-3 Toolset, and configuring
== Installing Eclipse
Download the latest 32- or 64-bit Eclipse package, according to your platform and OS version form https://www.eclipse.org/downloads/. All Eclipse solution packages are suitable, but if you want to develop also adapters and/or external C/C\++ functions, the "Eclipse IDE for C/C++ Developers" can be a good choice.
Download the latest 32- or 64-bit Eclipse package, according to your platform and OS version form https://www.eclipse.org/downloads/. All Eclipse solution packages are suitable, but if you want to develop also adapters and/or external C/C\++ functions, the "Eclipse IDE for C/{cpp} Developers" can be a good choice.
NOTE: The CDT package can also be added to any Eclipse installation later.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment