Hi Rick,
I'm still traveling and only have good Internet once in awhile. So I've
put off answering this. But thought I'd better do something about it.
The existing manifest was only needed for ooDialog. The important part is
the part to load the 6.0 common controls library:
<description>Open Object Rexx Interpreter.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="amd64"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
Since that is needed by any Windows GUI application to use the 6.0, or
later, version of the library, it seems odd to me that CMake wouldn't have
a way to do it, if it is generating its own manifest. Without it, the
pre-verison 6.0 is loaded automatically, which is essentially W2K controls.
It took me quite a bit of work to get it working originally. It needs to
be the manifest of the executable that loads the ooDialog extension, which
I didn't understand when I first started with it. I thought it was
sufficient to use it for ooDialog.dll.
So, if we can't get CMake to add the common controls part to the manifest
it generates, then I'll have to add the custom step. I won't be back at
home until after Memorial day. I'll work on it then if you haven't already
come up with something.
--
Mark Miesfeld
On Mon, May 5, 2014 at 4:17 AM, Rick McGuire <object.r...@gmail.com> wrote:
> This is mostly to get this question recorded for Mark for when he gets
> back from vacation.
>
> I'm currently running into some issues with the manifest file we're
> embedding in rexx.exe via an include within rexx.rc. Building this via
> this method causes a duplicate resource error because the cmake build tools
> generate a default manifest which gets embedded via the /MANIFEST and
> /MANIFESTFILE linker options. When the .rc file pulls in the second
> manifest, this creates the error.
>
> For now, I've commented out the link in rexx.rc that pulls in the manifest
> file, so the cmake build is using the one it generates. For the existing
> build, I've switched to rexx.mak file to use /MANIFEST and /MANIFESTFILE
> link options. We're going to run into this same issue with the oodialog
> executables when we get that portion working in cmake as well. I really
> don't understand the manifests and what information needs to be in there.
> The cmake-generated manifests and the ones we are using are quite
> different. Here is our version:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
> <assemblyIdentity
> version="1.0.0.0"
> processorArchitecture="amd64"
> name="RexxLA.ooRexx.rexx"
> type="win32"
> />
> <description>Open Object Rexx Interpreter.</description>
> <dependency>
> <dependentAssembly>
> <assemblyIdentity
> type="win32"
> name="Microsoft.Windows.Common-Controls"
> version="6.0.0.0"
> processorArchitecture="amd64"
> publicKeyToken="6595b64144ccf1df"
> language="*"
> />
> </dependentAssembly>
> </dependency>
> </assembly>
>
>
> and here is the cmake version:
>
>
> <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
> <security>
> <requestedPrivileges>
> <requestedExecutionLevel level='asInvoker' uiAccess='false' />
> </requestedPrivileges>
> </security>
> </trustInfo>
> </assembly>
>
> Note that cmake generates one of these for all of the dlls and exes.
>
>
> So, do we need to continue using our manifest version or can just allow the
> cmake defaults? Does the cmake version cause any problems with the other
> files? I've found information on how to use custom manifests, which involves
> disabling the automatic generation and then adding a post-processing step
> that uses a tool to add the custom manifest. A bit of a pain, but doable. I
> think I'd prefer to let cmake do the heavy lifting if we can.
>
>
> Rick
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
