<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 2:31 PM, Lectem <span dir="ltr"><<a href="mailto:lectem@gmail.com" target="_blank">lectem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="FR"><div class="gmail-m_-7427633827535608254WordSection1"><p class="MsoNormal">I think that you are looking for the toolchain files :</p><p class="MsoNormal"><a href="https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html" target="_blank">https://cmake.org/cmake/help/<wbr>v3.0/manual/cmake-toolchains.<wbr>7.html</a></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The other option is to use a cmake script to specify your variables which includes CMakelists.txt (or the other way around if you can modify the CMakelists.txt). This would be quite similar to ctests scripts.</p><p class="MsoNormal">Some good examples are in Daniel Pfeifer’s « Effective cmake » talk <a href="https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf" target="_blank">https://github.com/boostcon/<wbr>cppnow_presentations_2017/<wbr>blob/master/05-19-2017_friday/<wbr>effective_cmake__daniel_<wbr>pfeifer__cppnow_05-19-2017.pdf</a></p><p class="MsoNormal"> </p></div></div></blockquote></div><br clear="all"></div><div class="gmail_extra">Wow that PDF is refreshing I have started to see some of these changes to CMake creep in over the years.  Coming from Boost.Build pre 2009 I had always longed for CMake to model itself after Boost Build if only a little bit.<br><br></div><div class="gmail_extra">I had long ago complained... ok and still do..  about the underlying design, scope, documentation (lack of in some cases and misleading/bad examples see such as), and language problems of CMake. <br><br>such as: <br><br><a href="https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html">https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html</a> and  
<a href="https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#module:CMakePackageConfigHelpers">https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#module:CMakePackageConfigHelpers</a><br></div><div class="gmail_extra">which still leave the package developer to use or not use version, put package (find_package) files "wherever"<br></div><div class="gmail_extra"><br>project( proj_name VERSION 1.0) not having any bearing on CMAKE_INSTALL_PREFIX such as C:\Program Files\proj-name and not C:\Program Files\proj-name-1.0, cuz who doesn't want previous versions blasted away/written over by default?<br></div><div class="gmail_extra"><br><br>It got so bad that I wrapped CMake goop in my own macros (which I even posted as feature request at <a href="http://www.CMake.org/Bug/view.php?id=11807">http://www.CMake.org/Bug/view.php?id=11807</a> but no longer in existence - CMake's Mantis tracker ) to give concise boost.build inheritable (such as now  INTERFACE) like spec and in so doing probably violated or committed every bad practice in that pdf, but hey what choice did I have back then... in trying to keep previous projects building... not sure what choice I have now..  <br><br><div class="gmail_extra">What I resorted to at the time was I rolled own macros add_project_executable, add_project_library, and add_project_configuration.  Where add_project_configuration allowed project executables and libraries to inherit build properties from configurations:<br></div><div class="gmail_extra"><br><a href="http://slideplayer.com/slide/6139853/">http://slideplayer.com/slide/6139853/</a><br><a href="http://images.slideplayer.com/18/6139853/slides/slide_24.jpg">http://images.slideplayer.com/18/6139853/slides/slide_24.jpg</a><br></div><a href="http://images.slideplayer.com/18/6139853/slides/slide_25.jpg">http://images.slideplayer.com/18/6139853/slides/slide_25.jpg</a><br><br>I know I'll build a Meta Meta (yes that's two Meta's) Build Spec Generator to take CMake Build Spec and generate a new updated CMake build spec to be used to generate the build spec to build the code.. eureka!<br><br></div><div class="gmail_extra">add_library(Bar Interface) <br></div><div class="gmail_extra">target_definitions(Bar IINTERFACE BAR = 1) <br><br></div><div class="gmail_extra">might get around my need for my add_project_configuration macro and friends.<br><br></div><div class="gmail_extra">Sadly the name "add_library" to say add only #defines or include dirs could more appropriately be add_configuration when not adding a "true" library.  <br><br>Rather inheriting/using config properties and the statement:<br><br></div><div class="gmail_extra">INTERFACE libraries have no build specification <br></div><div class="gmail_extra">They only give usage requirements<br><br></div><div class="gmail_extra">Only adds to the affront on sensibilities, cuz if it's not a library and has no build spec... errr why the term "library".  <br><br>IMO:<br></div><div class="gmail_extra"><br><a href="https://cmake.org/cmake/help/latest/release/3.0.html?highlight=interface#properties">https://cmake.org/cmake/help/latest/release/3.0.html?highlight=interface#properties</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">add_library<br><br></div><div class="gmail_extra">should unlearn/forget interface and <br><br></div><div class="gmail_extra">add_config, add_buildspec, or some other more appropriate name for this.  I can understand the lazy logic where "libraries" are both inherited/consumed by libraries and exectuables so put it there kinda logic that must have resulted in this..<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>These changes still don't fix the cmake-package and ExternalProject_add problems and 3rd party developer cat herding I find myself doing these days on the internet.<br><div><div class="gmail_extra"><br><br></div></div></div>