Re: CMake: using boosts own package finding stuff, howto?

From: Dennis Luehring (dl.soluz_at_[hidden])
Date: 2021-07-16 08:17:42

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