[CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam

[Brian Davis]

On Tue, Aug 8, 2017 at 2:31 PM, Lectem <lectem at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170809/619bec71/attachment.html>