Mark,
Thanks for the answer. I did find a solution for this. It turns out to
possible to replace or merge additional manifest information into the
executables as a post-processing step. I wasn't really sure which .exe
files needed this, so I end up merging it into them all. If only ooDialog
needs this, then that can simplify things in the cmake file considerably
since I had to add a lot of WIN32 conditional stuff to do this.
Rick
On Wed, May 21, 2014 at 5:17 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
"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
