[boost] CMake: using boosts own package finding stuff, howto?

[Dennis Luehring via Boost]

in short: CMake does need to change (i'll need to wait for updates) to
support newer released boost versions

i've heard that Boost supports cmake now directly but i don't get the
direct cmake support of boost working with

my CMakeLists.txt


i know that CMake supports 1.75 in the lastest releases directly but
1.76 and 1.77 are still not on the list and i don't want

to wait for CMake release to test new features/betas etc.


my system:

Ubuntu 21.04/x64, CMake 3.19.4/3.21.0, GCC 10.x

Boost 1.75 (want to upgrade to 1.76 soon)

my boost build:
  mkdir ~/dev/3rdparty-liux-gcc
  cd ~/dev/3rdparty-linux-gcc
  wget
https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2
  tar -xf boost_1_75_0.tar.bz2
  ln -s boost_1_75_0 ./boost
  cd boost_1_75_0
  ./bootstrap.sh
  ./b2 --toolset=gcc cxxflags=-fPIC --build-dir=./_build
address-model=64 architecture=x86 link=static threading=multi
--with-graph --with-nowide --with-test --width-config --with-system
--with-filesystem --stagedir=./_x64
  ln -s _x64/lib lib

my simple test hierarchy:

boost_using_cmake_tests
boost_using_cmake_tests\_build
boost_using_cmake_tests\boost_using_cmake
boost_using_cmake_tests\boost_using_cmake\CMakeLists.txt
      cmake_minimum_required (VERSION 3.16)
      set(Boost_NO_BOOST_CMAKE TRUE)
      set(Boost_NO_SYSTEM_PATHS TRUE)
      project (using_boost_with_cmake)
      set( MY_THIRD_PARTY_LIBS "~/dev/3rdparty-linux-gcc" )
      set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost )
      set( BOOST_INCLUDEDIR ${BOOST_ROOT}/boost)
      set( BOOST_LIBRARYDIR ${BOOST_ROOT}/lib)
      find_package(Boost REQUIRED COMPONENTS unit_test_framework
filesystem system)

cmake run:

using 3.19.4 cmake without 1.75 support

~/dev/boost_using_cmake/_build$
../../cmake-3.19.4-linux-x86_64/bin/cmake ../boost_using_cmake/
-- The C compiler identification is GNU 10.3.0
-- The CXX compiler identification is GNU 10.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204
(message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326
(_Boost_COMPONENT_DEPENDENCIES)
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935
(_Boost_MISSING_DEPENDENCIES)
  CMakeLists.txt:14 (find_package)


CMake Warning at
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204
(message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326
(_Boost_COMPONENT_DEPENDENCIES)
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935
(_Boost_MISSING_DEPENDENCIES)
  CMakeLists.txt:14 (find_package)


CMake Warning at
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1204
(message):
  New Boost version may have incorrect or missing dependencies and imported
  targets
Call Stack (most recent call first):
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1326
(_Boost_COMPONENT_DEPENDENCIES)
/home/linux/dev/cmake-3.19.4-Linux-x86_64/share/cmake-3.19/Modules/FindBoost.cmake:1935
(_Boost_MISSING_DEPENDENCIES)
  CMakeLists.txt:14 (find_package)


-- Found Boost: /home/linux/dev/3rdparty-linux-gcc/boost (found version
"1.75.0") found components: unit_test_framework filesystem system
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/linux/dev/boost_using_cmake_tests/_build

it works but cmake 3.19.4 is missing direct support for 1.75 so its some
way "unsupported", cmake does not detect the correct lib names
automaticly, only some styles are working etc.

i've talked about the problem on the cmake forum and the answer was

https://discourse.cmake.org/t/fail-to-use-self-build-boost-1-75-under-ubuntu-linux-20-04-x64-with-cmake-default-and-3-19-4/2750/5

Brad King: "...However, Boost upstream now provides a proper CMake
package file BoostConfig.cmake which should work for using Boost in any
layout..."

1.75 is now directly supported by cmake - but now i want to use 1.76 and
the problem re-occures

i've tried serveral things to force cmake to use the boost own package
findings stuff without any success
i hope its possible to use 1.75 and 1.76 in the future without always
wait for cmake to support it directly

any hints what changes are needed with my CMakeLists.txt to support
boost own cmake package finding (and get rid of these problems)?




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Alexander Grund via Boost]

Am 15.07.21 um 09:17 schrieb Dennis Luehring via Boost:

You explicitely opt-out of Boosts CMake support:
set(Boost_NO_BOOST_CMAKE TRUE)
You set the wrong folder: set( BOOST_ROOT ${MY_THIRD_PARTY_LIBS}/boost )

The INCLUDEDIR/LIBRARYDIR are not required.

--> More generic: `export
CMAKE_PREFIX_PATH=$HOME/dev/3rdparty-linux-gc/boost_1_75_:$CMAKE_PREFIX_PATH`
Then you don't need ANY BOOST_*/Boost_* settings in your CML and can
simply call find_package

[Dennis Luehring via Boost]

thank you - works with cmake 3.19.4+ and boost 1.75/1.76

cmake 3.18.6 (the default under Ubuntu 21.04, and the version i started
the jouney with) still does not work and gives the unsupported messages

thats why initially setted all the paths that way

it seems that the mind version of cmake is 3.19.4 to support finding out
of the box - is that correct?

[Alexander Grund via Boost]

> it seems that the mind version of cmake is 3.19.4 to support finding out
> of the box - is that correct?

No, pretty much any CMake version works. Especially with the
CMAKE_PREFIX_PATH approach.
If it doesn't you misconfigured something

[Dennis Luehring via Boost]

you're right


using the CMAKE_PREFIX_PATH approach using environment or directly with
list(APPEND CMAKE_PREFIX_PATH ${HAAS_THIRD_PARTY_LIBS}/boost_1_76_0)

also works with 3.18.6 - but NOT using set( BOOST_ROOT
${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4


the CMake guys forgot(or maybe thought i already tried that) to point me
to CMAKE_PREFIX_PATH solution - what would have solved my problem instantly

and also said that my problem would be solved with 3.19.4) so i tried to
"fix" something unbroken based on a maybe not exact enough issue
description - my fault


thank you soo much

[Alexander Grund via Boost]

Am 15.07.21 um 11:08 schrieb Dennis Luehring via Boost:

> Am 15.07.2021 um 10:38 schrieb Alexander Grund via Boost:
>>> it seems that the mind version of cmake is 3.19.4 to support finding
>>> out
>>> of the box - is that correct?
>> No, pretty much any CMake version works. Especially with the
>> CMAKE_PREFIX_PATH approach.
>> If it doesn't you misconfigured something
>>
>
> you're right
>
>
> using the CMAKE_PREFIX_PATH approach using environment or directly with
> list(APPEND CMAKE_PREFIX_PATH ${HAAS_THIRD_PARTY_LIBS}/boost_1_76_0)
>
> also works with 3.18.6 - but NOT using set( BOOST_ROOT
> ${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4

I think the correct variable to set here would have been Boost_ROOT or
Boost_DIR
BOOST_ROOT is compatibility IIRC

[Alexander Grund via Boost]

> also works with 3.18.6 - but NOT using set( BOOST_ROOT
> ${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4

FWIW: BOOST_ROOT is honored since 3.19.0:
https://github.com/Kitware/CMake/commit/4b2a61946fdb77ab37b66b1d2b81d2d77453ca5d

Anyway I suggest to always use CMAKE_PREFIX_PATH for any dependency

[Dennis Luehring via Boost]

Am 15.07.2021 um 11:25 schrieb Alexander Grund via Boost:
> > also works with 3.18.6 - but NOT using set( BOOST_ROOT
> > ${MY_THIRD_PARTY_LIBS}/boost_1_76_0 ) - that works only with 3.19.4
>
> FWIW: BOOST_ROOT is honored since 3.19.0:
> https://github.com/Kitware/CMake/commit/4b2a61946fdb77ab37b66b1d2b81d2d77453ca5d

good to know

>
> Anyway I suggest to always use CMAKE_PREFIX_PATH for any dependency

same suggestion comes for the Qt guys when upgrading to Qt6


btw: i've copied the boost integration stuff from the internet

and many samples using the Boost_INCLUDE_DIR etc. are complete uppercase
- i've copied that two


but now i cleaned all my CMakeLists.txt + using CMAKE_PREFIX_PATH and
everything works as expected


another big thank you!

[Deniz Bahadir via Boost]

Am 15.07.21 um 09:17 schrieb Dennis Luehring via Boost:

One remark:

Here you are explicitly depending on CMake's `FindBoost` script, because
you neither use the `CONFIG` nor `NO_MODULE` argument (or any other
argument not specified in the basic signature) for `find_package`. [1]
Unless you explicitly set the `CMAKE_FIND_PACKAGE_PREFER_CONFIG`
variable `find_package` always tries the "Module" mode first. And if it
finds a suitable `Find*` script it will not try the "Config" mode (even
if the `Find*` script is unable to find the package).
That your `find_package(Boost ...)` call still tries the "Config" mode
(if you again remove the `Boost_NO_BOOST_CMAKE` variable or set it to
`FALSE`)is only due to the fact that the `FindBoost` script explicitly
tries the `Config` mode first (unless you set the `Boost_NO_BOOST_CMAKE`
variable to `TRUE`).

So, in general I always recommend to explicitly use `find_package` in
"Config" mode if one knows that the searched package was installed with
a config-file for importing.
For Boost this should be true since Boost 1.70.0. (Installing it without
the config-file is not very sensible.)


Happy cmaking,
Deniz


[1]
https://cmake.org/cmake/help/latest/command/find_package.html#full-signature-and-config-mode

--
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: deniz....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Dennis Luehring via Boost]

Am 15.07.2021 um 13:52 schrieb Deniz Bahadir via Boost:
> One remark:
>
> Here you are explicitly depending on CMake's `FindBoost` script, because
> you neither use the `CONFIG` nor `NO_MODULE` argument (or any other
> argument not specified in the basic signature) for `find_package`. [1]
> Unless you explicitly set the `CMAKE_FIND_PACKAGE_PREFER_CONFIG`
> variable `find_package` always tries the "Module" mode first. And if it
> finds a suitable `Find*` script it will not try the "Config" mode (even
> if the `Find*` script is unable to find the package).
> That your `find_package(Boost ...)` call still tries the "Config" mode
> (if you again remove the `Boost_NO_BOOST_CMAKE` variable or set it to
> `FALSE`)is only due to the fact that the `FindBoost` script explicitly
> tries the `Config` mode first (unless you set the `Boost_NO_BOOST_CMAKE`
> variable to `TRUE`).
>
> So, in general I always recommend to explicitly use `find_package` in
> "Config" mode if one knows that the searched package was installed with
> a config-file for importing.
> For Boost this should be true since Boost 1.70.0. (Installing it without
> the config-file is not very sensible.)
>
>
> Happy cmaking,
> Deniz

i've reworked my CMakeLists.txt using that schema, using
CMAKE_PREFIX_PATH and CONFIG

works for linux, windows - includes and libraries correctly set to
make/VStudio project


-------------------

cmake_minimum_required(VERSION 3.14)


project (my_test)

if(UNIX AND NOT APPLE)
  set( MY_BOOST_DIR "/home/linux/temp/boost_1_75_0/_x64/lib/cmake" )
else()
  set( MY_BOOST_DIR "D:/temp/boost_1_75_0/_x64/lib/cmake" )
endif()

list(APPEND CMAKE_PREFIX_PATH ${MY_BOOST_DIR})

add_executable(test test.cpp)

find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework)
message(STATUS "!! Boost_FOUND => ${Boost_FOUND}")

IF (Boost_FOUND)
  message(STATUS "!! Boost_INCLUDE_DIRS => ${Boost_INCLUDE_DIRS}")
  message(STATUS "!! BOOST_INCLUDE_DIR => ${BOOST_INCLUDE_DIR}")
  message(STATUS "!! BOOST_INCLUDEDIR => ${BOOST_INCLUDEDIR}")
  message(STATUS "!! Boost_LIBRARY_DIRS => ${Boost_LIBRARY_DIRS}")
  message(STATUS "!! BOOST_LIBRARYDIR => ${BOOST_LIBRARYDIR}")
  message(STATUS "!! Boost_LIBRARY_DIR => ${Boost_LIBRARY_DIR}")
  message(STATUS "!! Boost_LIBRARY_DIR_RELEASE =>
${Boost_LIBRARY_DIR_RELEASE}")
  message(STATUS "!! Boost_LIBRARY_DIR_DEBUG =>
${Boost_LIBRARY_DIR_DEBUG}")

  target_link_libraries(test ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
ENDIF()

------------------


the only thing i don't understand (after testing/working with serveral
"variants" of boost cmake integration) is

that not all of the find_package result-Vars are set - but this is the
first time that every CMake version or Platform returns absolute the
same results

but Boost_LIBRARY_DIRS is not set anymore - but maybe its just not needed

output: CMake 3.14,3.18,3.21 giving this output on windows and linux
(with a different path)

-- !! Boost_FOUND => 1
-- !! Boost_INCLUDE_DIRS => D:/temp/boost_1_75_0
-- !! BOOST_INCLUDE_DIR =>
-- !! BOOST_INCLUDEDIR =>
-- !! Boost_LIBRARY_DIRS =>
-- !! BOOST_LIBRARYDIR =>
-- !! Boost_LIBRARY_DIR =>
-- !! Boost_LIBRARY_DIR_RELEASE =>
-- !! Boost_LIBRARY_DIR_DEBUG =>

i know that some of these (nearly identical!!!) vars are
find_package-returns, cache-var or hints for finding the package - i
just print them all to understand whats happening


does that mean i've found the holy grail of clean boost cmake integration?

are the result correct that way (my co-worker said this "/lib/cmake" at
the end of CMAKE_PREFIX_PATH seems wrong - but Qt6 is it doing the same
way - so i think he is wrong)


thank for your help

[Alexander Grund via Boost]

> the only thing i don't understand (after testing/working with serveral
> "variants" of boost cmake integration) is
>
> that not all of the find_package result-Vars are set - but this is the
> first time that every CMake version or Platform returns absolute the
> same results
>
> but Boost_LIBRARY_DIRS is not set anymore - but maybe its just not needed

All of them are not needed at all and not set by the CONFIG files. The
FindBoost module has explicit code to add those for legacy reasons.
In "good" CMake you are supposed to use the targets so all those
variables don't matter for ages now.

> does that mean i've found the holy grail of clean boost cmake
> integration?

Not sure what you mean here.

> are the result correct that way (my co-worker said this "/lib/cmake" at
> the end of CMAKE_PREFIX_PATH seems wrong - but Qt6 is it doing the same
> way - so i think he is wrong)

It is a PREFIX path, so yes, the lib/cmake is wrong.

Besides that: CMakeLists should be independent of your environment.
So setting CMAKE_PREFIX_PATH with hard-coded paths to your local system
is wrong. You are supposed to set the CMAKE_PREFIX_PATH env variable,
e.g. in your bashrc, profile file or manually in the shell or install
boost to a standard path like /usr

[Dennis Luehring via Boost]

Am 16.07.2021 um 09:53 schrieb Alexander Grund via Boost:
> > the only thing i don't understand (after testing/working with serveral
> > "variants" of boost cmake integration) is
> >
> > that not all of the find_package result-Vars are set - but this is the
> > first time that every CMake version or Platform returns absolute the
> > same results
> >
> > but Boost_LIBRARY_DIRS is not set anymore - but maybe its just not needed
> All of them are not needed at all and not set by the CONFIG files. The
> FindBoost module has explicit code to add those for legacy reasons.
> In "good" CMake you are supposed to use the targets so all those
> variables don't matter for ages now.

im working in serveral different customer projects that use this legacy
style

which gets copied over and over - so everyone thinks that legacy stuff
is the "official" way

also many/most of the "examples" on the internet are using the legcy
style - more or less

in complete wrong way - that is the base i've started with


also the discussion on the cmake forum often contain tips that are very
legacy or even wrong

when it comes to boost integration - would be great to have some
HOW-to-do-it correct tutorial

on the boost web page (i did't found any good information on boost.org)


thank for clearing that all up, also thanks @Deniz

> > does that mean i've found the holy grail of clean boost cmake
> > integration?
> Not sure what you mean here.

as stated above - i saw every old dirty trick to use boost with cmake -
and now i think

most of them just completely wrong - that cost some days to figure it out

and the current solution is how i though it should be done (while
fighting with my co-workers)


now i need to make my other co-workers understand that

> > are the result correct that way (my co-worker said this "/lib/cmake" at
> > the end of CMAKE_PREFIX_PATH seems wrong - but Qt6 is it doing the same
> > way - so i think he is wrong)
>
> It is a PREFIX path, so yes, the lib/cmake is wrong.

it works with and without lib/cmake but i also got the feeling that its
not correct - thanks


so its just the path i used with --stagedir= while building boost

> Besides that: CMakeLists should be independent of your environment.
> So setting CMAKE_PREFIX_PATH with hard-coded paths to your local system
> is wrong. You are supposed to set the CMAKE_PREFIX_PATH env variable,
> e.g. in your bashrc, profile file or manually in the shell or install
> boost to a standard path like /usr

the hardcoded path are only in this example - normaly these are based on
cmake command line parameters or environment variables

[Alexander Grund via Boost]

> when it comes to boost integration - would be great to have some
> HOW-to-do-it correct tutorial

Sure:
find_package(Boost 1.71.0 REQUIRED COMPONENTS unit_test_framework) #
Optionally with CONFIG if you require a recent enough Boost
target_link_libraries(foo PUBLIC Boost::unit_test_framework)

Done. Nothing more than that. Plus it pretty much works for EVERY dependency

> and the current solution is how i though it should be done (while
> fighting with my co-workers)

Your current solution uses variables: target_link_libraries(test
${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
Replace that by the target, then you are fine

> now i need to make my other co-workers understand that

Tell them this: OOP is key. OOP in CMake means targets. Work with
targets and target_* functions, not e.g. `include_directories`

> it works with and without lib/cmake but i also got the feeling that its
> not correct - thanks
> so its just the path i used with --stagedir= while building boost

This is documented in the CMake docs, that CMake searchs the
<PREFIX>/lib/cmake folder:
https://cmake.org/cmake/help/v3.9/command/find_package.html#command:find_package

> the hardcoded path are only in this example - normaly these are based on
> cmake command line parameters or environment variables

Try to avoid touching  CMAKE_PREFIX_PATH in a CML unless you install
stuff in the same CMake to that path. Require users to export that env
variable instead.
This makes your files more portable. Having to set different env vars
for every software you install makes a mess.

[Peter Dimov via Boost]

Dennis Luehring wrote:
> if(UNIX AND NOT APPLE)
>   set( MY_BOOST_DIR "/home/linux/temp/boost_1_75_0/_x64/lib/cmake" )
> else()
>   set( MY_BOOST_DIR "D:/temp/boost_1_75_0/_x64/lib/cmake" )
> endif()
>
> list(APPEND CMAKE_PREFIX_PATH ${MY_BOOST_DIR})
>
> add_executable(test test.cpp)
>
> find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework)

In principle this can equivalently be

find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework
PATHS
"/home/linux/temp/boost_1_75_0/_x64"
"D:/temp/boost_1_75_0/_x64")

although in the real project the paths probably shouldn't be hardcoded in
the
CMakeLists.txt file.

>   target_link_libraries(test ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})

This should be

target_link_libraries(test Boost::unit_test_framework)

The variables are old style CMake and shouldn't be used nowadays.

[Dennis Luehring via Boost]

Am 16.07.2021 um 10:30 schrieb Peter Dimov via Boost:
>> � target_link_libraries(test ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})

> This should be
>
> target_link_libraries(test Boost::unit_test_framework)
>
> The variables are old style CMake and shouldn't be used nowadays.

is there some setting to get such usage as warning - or do i need to
follow the cmake documentation

to understand what nowdays prefered?

set(CMAKE_WARN_DEPRECATED TRUE) does not really help

i think im surrounded by many lines of legacy cmake code

[Deniz Bahadir via Boost]

Am 16.07.21 um 10:17 schrieb Dennis Luehring via Boost:

>
> when it comes to boost integration - would be great to have some
> HOW-to-do-it correct tutorial
>
> on the boost web page (i did't found any good information on boost.org)
>
>
> thank for clearing that all up, also thanks @Deniz
>
>
>> > does that mean i've found the holy grail of clean boost cmake
>> > integration?
>> Not sure what you mean here.
>
>
> as stated above - i saw every old dirty trick to use boost with cmake -
> and now i think
>
> most of them just completely wrong - that cost some days to figure it out
>
> and the current solution is how i though it should be done (while
> fighting with my co-workers)
>
>
> now i need to make my other co-workers understand that

<shameless_self_plug>

I always like to point interested people to my two CMake talks, where I
explain the difference between traditional and modern CMake and where I
also have some examples for how to use Boost with CMake:
* ["More Modern CMake"](https://youtu.be/y7ndUhdQuU8)
* ["Oh No! More Modern CMake"](https://youtu.be/y9kSr5enrSk)

</shameless_self_plug>


Best,
Deniz

--
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: deniz....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378

[Dennis Luehring via Boost]

Am 17.07.2021 um 19:59 schrieb Deniz Bahadir via Boost:
>> as stated above - i saw every old dirty trick to use boost with cmake -
>> and now i think
>>
>> most of them just completely wrong - that cost some days to figure it out
>>
>> and the current solution is how i though it should be done (while
>> fighting with my co-workers)
>>
>>
>> now i need to make my other co-workers understand that
> <shameless_self_plug>
>
> I always like to point interested people to my two CMake talks, where I
> explain the difference between traditional and modern CMake and where I
> also have some examples for how to use Boost with CMake:
> * ["More Modern CMake"](https://youtu.be/y7ndUhdQuU8)
> * ["Oh No! More Modern CMake"](https://youtu.be/y9kSr5enrSk)
>
> </shameless_self_plug>

thank you for these 2 hours visual freshup of my cmake knowledge :)

[Deniz Bahadir via Boost]

Am 19.07.21 um 14:14 schrieb Dennis Luehring via Boost:

> Am 17.07.2021 um 19:59 schrieb Deniz Bahadir via Boost:
>>> as stated above - i saw every old dirty trick to use boost with cmake -
>>> and now i think
>>>
>>> most of them just completely wrong - that cost some days to figure
>>> it out
>>>
>>> and the current solution is how i though it should be done (while
>>> fighting with my co-workers)
>>>
>>>
>>> now i need to make my other co-workers understand that
>> <shameless_self_plug>
>>
>> I always like to point interested people to my two CMake talks, where I
>> explain the difference between traditional and modern CMake and where I
>> also have some examples for how to use Boost with CMake:
>> * ["More Modern CMake"](https://youtu.be/y7ndUhdQuU8)
>> * ["Oh No! More Modern CMake"](https://youtu.be/y9kSr5enrSk)
>>
>> </shameless_self_plug>
>
>
> thank you for these 2 hours visual freshup of my cmake knowledge :)

You are welcome. And thank you for watching. :-)

--
BENOCS GmbH
Dipl.-Inform. Deniz Bahadir
Reuchlinstr. 10 D
10553 Berlin
Germany
Phone: +49 - 30 / 577 0004-22
Email: deniz....@benocs.com
www.benocs.com

Board of Management: Stephan Schroeder, Dr.-Ing. Ingmar Poese
Commercial Register: Amtsgericht Bonn HRB 19378