diff options
Diffstat (limited to 'CIAO/docs/new_components.html')
| -rw-r--r-- | CIAO/docs/new_components.html | 129 |
1 files changed, 0 insertions, 129 deletions
diff --git a/CIAO/docs/new_components.html b/CIAO/docs/new_components.html deleted file mode 100644 index db10fca2103..00000000000 --- a/CIAO/docs/new_components.html +++ /dev/null @@ -1,129 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<!-- $Id$ --> -<html> <head> -<title>Procedures to prepare a new component implementation</title> -</head> - -<body> -<h1>Preparing a new component implementation</h1> - -I am documenting the steps required to prepare a component implementation. -Personally, I prefer to set up a directory to contain only <b>one</b> -component implementation. I believe the procedures outlined below -will work if you have multiple component implementation in the same -IDL files. The purpose of this document is to record the procedures -and steps on how these files relate to each others and how they come -about during the development process.<p> - -Assuming we need to create a new component called -<code><b>Orc</b></code>. Below is the list of files you'll need to -deal with. Our goal is to greatly reduce the number of files you need -to deal with manually... - -<ol> - <li><font color="red"><code><b>Orc</b>.idl</code></font> - This is - the IDL file that contains the component and component home - definitions.<p> - - As you will eventually create 3 DLLs (or shared objects), you - will also need 3 sets of different export macros files as - following.<p> - - <li><code><b>Orc</b>_stub_export.h</code> - This file is generated - using the following command:<p> - - <code>generate_export_file.pl <b>ORC</b>_STUB > <b>Orc</b>_stub_export.h</code><p> - - This file makes macros like <code><b>ORC</b>_STUB_Export</code> - and friends available. They are usually controlled by - <code><b>ORC</b>_STUB_BUILD_DLL</code><p> - - <li><code><b>Orc</b>_svnt_export.h</code> - This file is generated - using the following command:<p> - - <code>generate_export_file.pl <b>ORC</b>_SVNT > <b>Orc</b>_svnt_export.h</code><p> - - This file makes macros like <code><b>ORC</b>_SVNT_Export</code> - and friends available. They are usually controlled by - <code><b>ORC</b>_SVNT_BUILD_DLL</code><p> - - <li><code><b>Orc</b>_exec_export.h</code> - This file is generated - using the following command:<p> - - <code>generate_export_file.pl <b>ORC</b>_EXEC > <b>Orc</b>_exec_export.h</code><p> - - This file makes macros like <code><b>ORC</b>_EXEC_Export</code> - and friends available. They are usually controlled by - <code><b>ORC</b>_EXEC_BUILD_DLL</code><p> - - <li><code><b>Orc</b>E.idl</code> - Component Executor equivalent - interface definitions. This file should be generated - automatically by the CIDL compiler as illustrated in this - <a href="com-impl.html">file</a> but we currently are still - working on the implementation of the CIDL compiler. Therefore, - you still need to create this file manually.<p> - - <li><font color="red"><code><b>Orc</b>EI.idl</code></font> - - Optional Component Executor implementation interface - definitions. Often time, when you implement a non-trivial - monolithic component implementation, you are required to define - the monolithic local executor interface which often inherits - from the component monolithic executor interface and all the - provided interfaces. The actually executor implementation will - inherit from this user defined interface instead of the default - executor mapping defined in <code><b>Orc</b>E.idl</code>. You - will need to do the same when you wish to support non-vanilla - component interface, such as - <code>Components::SessionComponent</code>, and/or - <code>Components::SessionSynchronization</code>.<p> - - Ideally, it would be perfect if we can auto-generate this - optional IDL file using CIDL compiler. However, I'm not sure - the plan CIDL language contains enough information that's - required to generate this file.<p> - - <li><font color="red"><code><b>Orc</b>_exec.*</code></font> - These - are files containing the actually component implementation that - you have to write manually. It, however, depends on the - equivalent executor IDL definition (that will be) generated by - the CIDL files.<p> - - <li><code><b>Orb</b>_svnt.*</code> - These are files containing the - servant glue code that bridge a container to the component - executor that you implement. Like the component executor - mapping IDL file, these files should be generated by the CIDL - compiler but are currently generated manually.<p> - - <li><code><b>Orc</b>.csd</code> - Component Softpkg Descriptor. We - need some kind of tool to generate this file automatically. It - is currently being generated manually, however.<p> - - - <li><code><b>Orc</b>.ssd</code> - Servant Softpkg Descriptor. This - is a CIAO extension descriptor file which uses the same softpkg - DTD as described in CCM spec. CIAO requires this file because - CIAO separates the executors into a completely separate DLL. - Like <code><b>Orc</b>.csd</code>, this file should be generated - automatically through some tool, but it is currently manually - crafted.<p> - - <li><code><b>Orc</b>.ccd</code> - CORBA Component Descriptor. This - file is currently being generated manually thou a template - should really be generated by CIAO's CIDL compiler.<p> - - <li><font color="red"><code><b>Orc</b>.mpc</code></font> - Makefile - Project Creator definition file. There is a perl script to - generate a minimal MPC definition at - <code>$(CIAO_ROOT)/bin/generate_component_mpc.pl</code> so - people can use it to implement the simplest component - implementation outlined in this file.<p> - -</ol> - - -<hr> -<address></address> -<!-- hhmts start --> -Last modified: Fri Mar 21 16:06:48 Central Standard Time 2003 -<!-- hhmts end --> -</body> </html> |