Code generator does not include custom types

[jasper]

Suppose there is a custom type IDL "MyTypes?" and the raw C-interfaces generated from that are in a header file "MyTypes?.h", the wrappers are in "MyTypeWrappers?.h" and the adapters are in "MyTypeAdapters?.h", then any implementation that refers to the wrappers needs:

#include "MyTypes.h"
#include "MyTypeWrappers.h"

and any implementation that needs the adapters needs at least

#include "MyTypes.h"
#include "MyTypeAdapters.h"

but more typically the adapters will themselves refer to the wrappers, so

#include "MyTypes.h"
#include "MyTypeWrapers.h"
#include "MyTypeAdapters.h"

These include statements are not generated by the code generator. It is also somewhat hard to do so as the code generator is not aware of the names of these header files as they are generated in a previous code generation step.

For CAPE-OPEN types this is not a problem, as the above includes are, in the correct order, already available through the COBIA.h client header.

For custom types the compiler errors however many not immediately tell the developer what is wrong, if the includes are missing, and how to fix it.

Options include

• the code generator provides textual output at code generation time which headers are needed
• the user must provide the header file paths as input to the code generator, and the header files are included by the code generator
• the code generator places comments or error pragmas in the code to alert the user to include the appropriate files (disadvantage of this approach is that the code generator cannot detect that the types are already included and may generate such comments or error pragmas redundantly)
• we do nothing and have the developer sort it out
• other (please suggest)

[jasper]

Additional options

• use standard naming for the generated interface, wrapper and adapter headers

Also it would be good if the files are self contained, e.g. include the wrappers in the adapter header, include the interfaces in the wrapper header

[kyle]

Third party extensions could resolve this.

Leave as is until the documentation phase.