Mailing List cwmm-dev@2rosenthals.com Archived Message #23

From: "Dave Yeo" <cwmm-dev@2rosenthals.com> Full Headers
Undecoded message
Subject: Re: [cwmm-dev] Compiling cwwm
Date: Mon, 27 Jul 2020 23:08:26 -0700
To: CWMM Developers Mailing List <cwmm-dev@2rosenthals.com>

On 07/27/20 10:06 PM, Steven Levine wrote:
In <list-933481@2rosenthals.com>, on 07/27/20
   at 09:39 PM, "Dave Yeo" <cwmm-dev@2rosenthals.com> said:

Hi Dave,

Shame
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
with OS/2.

The som.hh included with VACPP3.08 has,
// som.hh for DTS C++
// SHD: May 27/94


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.

Well, Chris uses .hh files and I did have that crash when trying an xh version, possibly due to not having enough string space, the .hh files use -S128000.


created the needed hh files from the toolkit's idl files but  there are
missing includes I believe. Eg now I get errors like, ...
K:\work\cwmmclasses\branches\v2.9\common_functions\include\wpfsys.hh(272:35)
: error EDC3090: Syntax error - expected "type name" and found
"FILTERFLAGS".
...
which seems to be typedefed in wpobject.h and likely wpobject.idl and/or
wptypes.idl.

My guess is that this code expects to be built with the wpobject.h
provided by xworkplace.

Looking, I see intree, _wpobject.h, __wpobject.h which is about 8k smaller as well as wpobject.hh, need to investigate why one isn't getting included and still left wondering. There's other system files that Chris included and added a leading _ They're all pretty old.


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.

Those are only accessed by classes, need to access from mediafolder. I'm reluctant to mix them.


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."

Some don't have corresponding idl files, and no code to build the ones using system idl files. I'll assume using the toolkit versions is preferred.
Dave
Dave

--
This email was Anti Virus checked by Astaro Security Gateway. http://www.sophos.com

Subscribe: Feed, Digest, Index.
Unsubscribe
Mail to ListMaster