On Tue, Aug 8, 2017 at 2:31 PM, Lectem <lec...@gmail.com> wrote: > I think that you are looking for the toolchain files : > > https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html > > > > 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. > > Some good examples are in Daniel Pfeifer’s « Effective cmake » talk > https://github.com/boostcon/cppnow_presentations_2017/ > blob/master/05-19-2017_friday/effective_cmake__daniel_ > pfeifer__cppnow_05-19-2017.pdf > > >
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. 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. such as: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html and https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#module:CMakePackageConfigHelpers which still leave the package developer to use or not use version, put package (find_package) files "wherever" 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? It got so bad that I wrapped CMake goop in my own macros (which I even posted as feature request at http://www.CMake.org/Bug/view.php?id=11807 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.. 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: http://slideplayer.com/slide/6139853/ http://images.slideplayer.com/18/6139853/slides/slide_24.jpg http://images.slideplayer.com/18/6139853/slides/slide_25.jpg 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! add_library(Bar Interface) target_definitions(Bar IINTERFACE BAR = 1) might get around my need for my add_project_configuration macro and friends. 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. Rather inheriting/using config properties and the statement: INTERFACE libraries have no build specification They only give usage requirements Only adds to the affront on sensibilities, cuz if it's not a library and has no build spec... errr why the term "library". IMO: https://cmake.org/cmake/help/latest/release/3.0.html?highlight=interface#properties add_library should unlearn/forget interface and 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.. 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.
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake