<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 9:07 PM Brad King <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 09/17/2018 04:01 AM, Rolf Eike Beer wrote:<br>
> I suggest that every module included from the CMake installation is <br>
> considered clean for whatever we do and automatically gets a policy <br>
> scope push/pop right from the C++ level.<br>
<br>
That's fine with me for policies like CMP0057 that affect the<br>
CMake language features.  We can't do that for every policy<br>
because some policies affect the way modules behave for the<br>
calling project.<br>
<br>
When include() or find_package() establishes the policy scope<br>
for the included module we can inject a few settings.<br></blockquote><div><br></div><div>We may also need to be careful about CMP0011 (Included scripts do automatic cmake_policy PUSH and POP), since that has come up before with regard to why some modules needed explicit policy push-pop even though include() would normally do that for us automatically.</div><div><br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div><div><br></div><div>New book released: <a href="https://crascit.com/professional-cmake/" target="_blank">Professional CMake: A Practical Guide</a><br></div></div></div></div></div></div></div></div></div></div>