<div dir="ltr">Hi Again,<div><br></div><div>I was asked to link to the background discussion for this (good point!). The actual post was:</div><div>    <a href="https://lists.boost.org/Archives/boost/2017/07/237490.php">https://lists.boost.org/Archives/boost/2017/07/237490.php</a><br></div><div><br></div><div>and there's quite a bit of talk in that thread and a few similarly-named others about CMake. This announcement seems to have stirred up some old/new controversies, and I'm pretty sure there is a decent amount of misunderstanding/old assumptions about CMake.</div><div><br></div><div>I was just rather taken back by this statement because I've been trying to research "Modern" CMake and hadn't encountered anything like this. Perhaps I'm merely imagining something wildly different from the intention.</div><div><br></div><div>Nick</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5">On Mon, Jul 24, 2017 at 7:46 PM, Nicholas Devenish <span dir="ltr"><<a href="mailto:ndevenish@gmail.com" target="_blank">ndevenish@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><div>Seen in the boost discussions on the CMake announcements:</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> The rest can be implemented straightforwardly as cache options so that<br>> you can run cmake with options like<br>><br>>   -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D…]<br>...</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Secondly, in cmake 3 we try not to configure things using -D as we did<br>in cmake 2. Instead we make targets customised for that build<br>combination. The user then chooses to make or link to those targets if<br>they want those targets.<br></blockquote><div> </div><div>Is this true, and is there a good example of a project with such a configuration?</div><div><br></div><div>I've been trying to learn the more modern approaches to writing CMakeLists recently, and haven't come across such advice - I was under the impression that cache-set options (that the build can make decisions on) was still the recommended 'clean' way, and then options (and even extra sources, dependencies) can be added to each target as required.</div><div><br></div><div>As I imagine what this is saying, It seems that target-per-configuration would just lead to an explosion of duplicated targets and duplicated code, especially through every permutation of several different options? </div><div><br></div><div>Part of the niceness of target-oriented dependencies was just having one thing to link to and depending on the configuration, that target would be the correct one (and pass through it's configuration).</div><div><br></div><div>Nick</div></div></div></div></blockquote></div></div></blockquote></div></div></div>