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

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
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:


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".




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: 

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 

Follow this link to subscribe/unsubscribe:

Reply via email to