Re: [boost] Follow-up to the follow-up of the CMake follow-up

Subject: Re: [boost] Follow-up to the follow-up of the CMake follow-up
From: paul (pfultz2_at_[hidden])
Date: 2017-07-13 22:14:55

On Thu, 2017-07-13 at 12:58 -0700, Louis Dionne via Boost wrote:
> > 
> > On Thu, 2017-07-13 at 10:55 -0700, Louis Dionne via Boost wrote:
> > > 
> > > > 
> > > > 
> > > > In branch feature/install-cmake-config-2 of the superproject, you can
> > > > find 
> > > > an improved version of the award-winning work presented in my
> > > > previous 
> > > > follow-up. This one integrates into the top-level "b2 install" and
> > > > "b2Â 
> > > > stage" and installs (or, respectively, stages) the CMake configuration
> > > > files 
> > > > necessary for find_package to work.
> > > > 
> > > > [...]
> > > I think this is a very good start! It shows that we can automate part of
> > > the
> > > process of creating the CMake XYZConfig.cmake files for existing
> > > libraries,
> > > which is nice. However, the resulting XYZConfig files are not always
> > > sufficient,
> > > for example Boost.Interprocess, which requires additional libraries to
> > > link.
> > > Specifically, the config file for Boost.Interprocess would need to
> > > specify 
> > > something along the lines of:
> > > 
> > > Â  if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux")Â 
> > > Â Â Â Â target_link_libraries(boost_interprocess INTERFACE -lrt)
> > > Â  endif()Â 
> > Actually, using the scripts I have here:
> > 
> > https://github.com/pfultz2/boost-cmake
> > 
> > This will let you inject extra cmake code for projects. That's how I
> > generate
> > code for Boost.Context, which needs a lot of custom work. The same could
> > be
> > done for Boost.Interprocess. Its fairly simple to add if you would like to
> > add
> > your patches.
> > 
> > It currently can build all of boost, but there is some more work that
> > needs to
> > be done, including adding more tests, and disabling libraries such as MPI
> > or
> > Python that need external dependencies.
> I looked quickly at your solution, and it appears that you're writing quite
> a bit of custom CMake code (and I don't see how things could be any
> different).

Not really writing any custom cmake code. It essientially follows Daniel's
effective cmake. Where are you seeing custom cmake code?

The only part is that I check the dependencies are available before I link
them, so I write:

if(boost_core_FOUND)
target_link_libraries(boost_hana INTERFACE boost::core)
endif()

I would like to change that. This was kind of hack to make some libraries
optional. I need to think about better supporting optional boost libraries
from the `add_subdirectory` level. That is the user may not want to build
python or mpi, so there should be a way to disable them, however, some
libraries will still look for those dependencies. I think this is more of a
problem of the mess of dependencies we have now. Hopefully, I can find a
cleaner solution.

> This also appears to be missing some things like the fact that Hana has a 
> requirement on C++14:
> 
> Â  target_compile_features(hana INTERFACE cxx_std_14)
> 

I dont do that because:

* It doesnt work with cmake 3.5, which is what I am targeting
* It can break ABI compatibilty adding in a C++14 flag. 
* It also doesnt work with C++ versions it doesnt know about, such as C++AMP
or C++20.

If users want to use C++14 it should be added to the toolchain, that way all
libraries compile with it, which makes all ABIs consistent. For now, Hana can
just check if the features necessary are avaiable during configure, and stop
if the toolchain does not have a C++14 capable compiler. 

Once this features matures more with cmake, we should definitely start using
it, but its just not there yet.

> Or are you reusing Hana's CMakeLists.txt? 

No, because Hana's cmake uses `find_package(Boost)`, which will not find its
dependencies correctly nor does Hana makes its dependencies transitive in its
config cmake file. Instead, I generated cmake to use and generate the proper
cmake config files.

> I'm not sure that's going to work 
> out of the box, since I have not written Hana's CMakeLists.txt with the idea
> that one would use it through add_subdirectory.

True, but the generated one will work both standalone and through
`add_subdirectory`. Of course, it doesn't run the tests, and there maybe more
changes we want to make.

> 
> I think your (and Peter's) tools are really cool and they show us how we can
> use tooling to help us migrate if/when we decide to do so. In the end, I do
> believe we'd have some manual work to do, but that's fine IMO.

When we want to support cmake running the tests, there will be a lot of manual
work with that. I don't see an easy way to automate it.

The nice thing about the automated scripts is we could use them to provide
"experimental" versions of boost cmake now, so we can guage user demand for
cmake. We just need some testing infrastructure to ensure that the plumbing is
correct.