In <cc8cb9aa-de9a-d698-c8de-737aa2787c87@gmail.com>, on 07/19/20
at 02:48 PM, Dave Yeo <dave.r.yeo@gmail.com> said:
Hi Dave,
Moving this to new list...
>They seem to all be part of the final packaging stage.
I did not look all that closely at why the directories were being created.
I guess it could just be omitted functionality or just lost source code.
>wl.exe and wrc.exe doesn't like GCC 2.8.1's output :)
Well, wl does not like gcc's default output all that much either. :-)
>Yes, the first part of the compile involves generating quite a few hh
>files out of idl files.
Some of these .idl files, such as wpdataf.idl, are part of the toolkit as
is wpdataf.h and wpdataf.xh. Others such as wpdataf.hh are not, so you
need to generate them if your code needs them and it appears the cwmm
does. The .hh files are used by code that uses the DTS interface. See
the SOM Programming Guide in the toolkit for the details.
>No sign of progfolder*
Perhaps this one got lost. For now, comment anything that requires it out
of the build, which means don't build progfldr.dll/progfolder.dll.
>and wpdataf.hh seems to
>be a system header
It's not.
>as it is surrounded by <> and the only wpdataf.*
>files I find are in the toolkit and no hh file.
wpdataf.h is provided by the toolkit, so it can be considered a system
header. Keep in mind that the only thing that <> does is change the
include search order. Whether or not a file is system header is somewhat
a matter of POV.
The lack of a wpdataf.hh is not a problem because none of the code
requires it, which explains why the make files don't create it.
>All but those 2 are generated. I assume that progfolder.hh should be
>generated from progfolder.idl or be referenced somewhere other then an
>include line in the source.
We need to track down progfolder.idl, but that can happen in parallel with
getting everything else to build.
You might try turning off optimization and see if that works around the
compiler defect.
tilbake listen