<table><tr><td style="">kossebau added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D25589">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D25589#570375" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D25589#570375</a>, <a href="https://phabricator.kde.org/p/dfaure/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@dfaure</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>My head hurts a bit but I think I understand this now ;)</p></div>
</blockquote>

<p>Indeed, this gets more & more complex, I hope in time for ECM6 there are enough samples collected from real-world usage to trim down things a bit again, to match known usage pattern with some simple setup options again. For now it's still try & error phase I guess, at least I still meet new constellations every week I had not thought of when initially designing this.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>I'm not sure what's the use case for disabling this though? (I'm wondering the same about the existing NO_DEFINITION_EXPORT_TO_BUILD_INTERFACE)</p></blockquote>

<p>With some non-KDE projects I experimented this with, having control to disable the setting or build-internal export of these flags was needed.<br />
E.g. in  some the examples wanted to have all deprecated API be invisible, to make sure examples only demonstrate latest non-deprecated API. So the exported flags were not wanted, instead are explicitly set per tests & examples.<br />
In others deprecated API was more separate and should not be used from other parts, so having a global deprecation warning/visibility flag by default got in the way, where instead deprecation warnings/visibility trigger is individually configured per file (warnings vs. visibiity to allow smooth porting in the library).</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R240 Extra CMake Modules</div></div></div><br /><div><strong>BRANCH</strong><div><div>NO_BUILD_SET_DEPRECATED_WARNINGS_SINCE</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D25589">https://phabricator.kde.org/D25589</a></div></div><br /><div><strong>To: </strong>kossebau, Build System, Frameworks, dfaure<br /><strong>Cc: </strong>kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns<br /></div>