In <email@example.com>, on 07/27/20
at 09:39 PM, "Dave Yeo" <firstname.lastname@example.org> said:
>the toolkit doesn't have .hh versions for most of the idl files.
The .hh files for for the C++ DTS (Direct to SOM) bindings. This method
of interacting with SOM objects was probably invented after IBM was done
You can always use sc to generate any .hh file you might need. However,
you probably don't need them. If your code was written to use the
traditiional C++ .xih bindings, you don't need the DTS .hh files.
>created the needed hh files from the toolkit's idl files but there are
>missing includes I believe. Eg now I get errors like, ...
> : error EDC3090: Syntax error - expected "type name" and found
>which seems to be typedefed in wpobject.h and likely wpobject.idl and/or
My guess is that this code expects to be built with the wpobject.h
provided by xworkplace.
>I guess experiment and hopefully figure it out.
>Is there a common variable to refer to the toolkit?
Do you mean in makefiles? If so, it varies. Xworkplace uses TKBASE.
I've seen other code that uses TOOLKIT.
>Rather then copying the idl files to the tree,
You are absolutely correct that committing the .idl files you don't
maintain into your tree is a bad idea.
>it may be better to
>just tell sc where to install them and create a permanent include
>directory for the hh files.
The .xih, .ih and .hh files are all build products. In the case of .hh
files you generate, my inclination would be to write them to the same
directory where the .ih and .xih files are written.
Any .ih, .hh and .xih files that are in the repo are only there because
they were part of the initial import. Recall that I stated:
"It is also likely that some build products were committed to the trunk.
If so, they should be "svn removed" from the trunk."