<div dir="ltr">Yes, I believe this is still a problem in the current development version of cmake, in that /MANIFESTUAC:NO is not correctly processed. (And, by the way, my previous comment about this potentially being fixed by a restructuring was probably due to my mis-reading of the code.)<div>
<br></div><div>Ultimately, however, to do my testing I did go back to using the v2.8.12.2 tag source code. After looking at cmIDEOptions::CheckFlagTable to understand the processing of the Visual Studio linker flags processing better, I believe that the /MANIFESTUAC:NO option needs to simply force the EnableUAC attribute to "false". I'm not sure why there are multiple entries in the table (which might mean I'm missing something here) but doing the following replacment in cvVS11LikFlagTable.h seemed to fix the problem:</div>
<div><br></div><div><div>diff --git a/Source/cmVS11LinkFlagTable.h b/Source/cmVS11LinkFlagTable.h</div><div>index b4587a8..0f641e4 100644</div><div>--- a/Source/cmVS11LinkFlagTable.h</div><div>+++ b/Source/cmVS11LinkFlagTable.h</div>
<div>@@ -217,10 +217,7 @@ static cmVS7FlagTable cmVS11LinkFlagTable[] =</div><div> {"LinkDLL", "DLL", "", "true", 0},</div><div> </div><div> //Bool Properties With Argument</div>
<div>- {"EnableUAC", "MANIFESTUAC:NO", "", "false",</div><div>- cmVS7FlagTable::UserValueIgnored | cmVS7FlagTable::Continue},</div><div>- {"EnableUAC", "MANIFESTUAC:NO", "Enable User Account Control (UAC)", "",</div>
<div>- cmVS7FlagTable::UserValueRequired},</div><div>+ {"EnableUAC", "MANIFESTUAC:NO", "", "false", 0},</div><div> {"EnableUAC", "MANIFESTUAC:", "", "true",</div>
<div> cmVS7FlagTable::UserValueIgnored | cmVS7FlagTable::Continue},</div><div> {"UACUIAccess", "MANIFESTUAC:", "Enable User Account Control (UAC)", "",</div></div><div><br></div>
<div>I built a project with a version of cmake with this patch applied and I did get executables without a "requestedExecutionLevel" manifest embedded in it, and that was the behavior I was looking for (we apply our manifests manually after the build process since it simplifies our management of the manifest generation).</div>
<div><br></div><div>If this is correct, similar changes would be necessary in the VS10 and VS12 tables as well. One of the reasons I thought this was correct was that the inclusion of the 2nd rule for MANIFESTUAC:NO seems to imply there is a syntax where there are additional values appended to MANIFESTUAC:NO but I do not believe this to be the case. The only other thing that wasn't clear to me was whether MANIFESTUAC:NO has additional impact on the UACExecutionLevel and UACUIAccess attributes but I was assuming these values were unnecessary if EnableUAC was false. Hopefully that is correct.</div>
<div><br></div><div>I suppose the code was trying to deal with the very general syntax of the /MANIFESTUAC: option, which can be in the following forms:</div><div><br></div><div><pre style="padding:5px;margin-top:0px;margin-bottom:0px;overflow:auto;word-wrap:normal;color:rgb(0,0,0);font-size:13px;line-height:17.549999237060547px;font-family:Consolas,Courier,monospace!important">
/MANIFESTUAC
/MANIFESTUAC:NO
/MANIFESTUAC:fragment
/MANIFESTUAC:level=_level
/MANIFESTUAC:uiAccess=_uiAccess</pre></div><div class="gmail_extra"><br>With the "fragment" form being the most problematic (I don't think the table-drive approach can easily handle that syntax (which is probably fine because that syntax is a bit ugly IMHO), and the synopsis of the "fragment" syntax is:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"> /MANIFESTUAC:<span style="color:rgb(0,0,0);font-family:Consolas,Courier,monospace;font-size:13px;line-height:17.549999237060547px">"level=[ asInvoker | highestAvailable | requireAdministrator ] uiAccess=[ true | false ]"</span></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">However I suppose there might be a possibility of having the setting of just "level" and "uiAccess" with a rule for "/MANIFESTUAC:level=" and "MANIFESTUAC:uiAccess=" with a "UserValueRequired" "special" flag. I'm not asking for this directly, as it is the "MANIFESTUAC:NO" case that I care about most, but I thought I'd mention this as a potential enhancement. It still doesn't address the "fragment" case, but perhaps that's ok.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">So the diff I include above I believe will help the /MANIFESTUAC:NO case but not provide full support for all the variants of /MANIFESTUAC. But I think it would be a step in the right direction although perhaps I'm missing some of the issues here and am interested in whatever input you might have regarding the appropriateness of this for inclusion in cmake.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But, should the above analysis be largely correct, I'd like to request that this be considered for a 2.8.12.X update or at least future versions of cmake.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I'm definitely willing to submit this fix through more official review channels, but I thought I'd post this here for an initial check on my understanding.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Eric Berge</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
<br><div class="gmail_quote">On Fri, May 2, 2014 at 1:42 PM, Eric Berge <span dir="ltr"><<a href="mailto:ericmberge@gmail.com" target="_blank">ericmberge@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Experiments with today's git master branch are inconclusive at this point. There's something causing errors with my tree that don't occur with 2.8.12.2, but it did generate the cvproj file and, in spite of the restructuring of the vcproj generation, it looks like the GenerateManifest value is still true. I just wish I could have actually gotten the build to generate the associated executable so I could have confirmed this more strongly by examining the embedded manifest.<div>
<br></div><div>So I'm expecting this is still a problem, but I'm not sure. I'll do some more experimentation and update this with anything I find.</div><div><br></div></div><div class=""><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Fri, May 2, 2014 at 11:47 AM, Eric Berge <span dir="ltr"><<a href="mailto:ericmberge@gmail.com" target="_blank">ericmberge@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Note that this was based on 2.8.12.2 but looking at the more recent code I think there's a possibility that a fix for this "fell out" of a restructuring of the generation of the vcproj files. I'm going to try to build this and see if the problem appears to be fixed.<div>
<br></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 10:59 AM, Eric Berge <span dir="ltr"><<a href="mailto:ericmberge@gmail.com" target="_blank">ericmberge@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I am updating our cmake files from Visual Studio 2008 to 2012 and the setting of CMAKE_EXE_LINKER_FLAGS to include /MANIFESTUAC:NO (which worked with VS2008) appears to be ignored. The resulting exe files have the following manifest in them:</div>
<div><br></div><div><div><?xml version='1.0' encoding='UTF-8' standalone='yes'?></div><div><assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'></div>
<div> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"></div><div> <security></div><div> <requestedPrivileges></div><div> <requestedExecutionLevel level='asInvoker' uiAccess='false' /></div>
<div> </requestedPrivileges></div><div> </security></div><div> </trustInfo></div><div></assembly></div></div><div><br></div><div>I'm not sure, but I believe this is due to the following being included for the RelWithDebInfo build I'm doing:</div>
<div><br></div><div><GenerateManifest Condition="'$(Configuration)|$(Platform)'=='RelWithDebInfo|x64'">true</GenerateManifest><br></div><div><br></div><div>and I expect this should be "false" (but I'm not sure whether there are other parts of the Visual Studio project file that need to be updated as well.</div>
<div><br></div><div>I believe this is another manifestation or is at least related to issue 12963 - <a href="http://public.kitware.com/Bug/view.php?id=12963" target="_blank">http://public.kitware.com/Bug/view.php?id=12963</a></div>
<div><br>
</div><div>So I'm probably requesting that issue be bumped from "backlog" status.</div><span><font color="#888888"><div><br></div><div>Eric</div><div><br></div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>