Follow-up to the follow-up of the CMake follow-up

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Follow-up to the follow-up of the CMake follow-up

Boost - Dev mailing list
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.

The instructions for trying it out are the same as last time:

git clone --recursive --depth 64 -b feature/install-cmake-config-2
https://githib.com/boostorg/boost
bootstrap
b2 headers
b2 install

then add the installation prefix to CMAKE_PREFIX_PATH. An example
CMakeLists.txt could look like this:

cmake_minimum_required(VERSION 3.5)

project(cmake_demo CXX)

list(APPEND CMAKE_PREFIX_PATH C:/Boost)

find_package(boost_filesystem 1.63.0 REQUIRED)
find_package(boost_program_options 1.63.0 REQUIRED)

# disable autolink

add_definitions(-DBOOST_ALL_NO_LIB=1)

# sample program

add_executable(cmake_demo cmake_demo.cpp)
target_link_libraries(cmake_demo boost::filesystem boost::program_options)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Boost - Dev mailing list
> 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.

... and I'm grateful to Rene Rivera and Vladimir Prus for their patient help
with Boost.Build.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Jul 5, 2017 at 8:39 PM, Peter Dimov via Boost
<[hidden email]> wrote:
> list(APPEND CMAKE_PREFIX_PATH C:/Boost)

Is this right? Hard-coding the path of a dependency doesn't look right.


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Boost - Dev mailing list
Olaf van der Spek wrote:
> On Wed, Jul 5, 2017 at 8:39 PM, Peter Dimov via Boost
> <[hidden email]> wrote:
> > list(APPEND CMAKE_PREFIX_PATH C:/Boost)
>
> Is this right? Hard-coding the path of a dependency doesn't look right.

That's just my test CMakeLists.txt. You don't have to copy it.

I grew tired of specifying -DCMAKE_PREFIX_PATH on each configure.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Louis Dionne
In reply to this post by Boost - Dev mailing list
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()

I don't think these things can be generated automatically, and I expect
that a number of libraries will require manual attention to provide proper
integration.

Louis
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Boost - Dev mailing list
Louis Dionne wrote:

> 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()

Yes, and there's also the problem that some libraries don't have the same
name as their directory. Specifically, Test and Stacktrace, but there may be
others. There was also Math, but I made it header-only.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Boost - Dev mailing list
In reply to this post by Louis Dionne
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Louis Dionne
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).
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)

Or are you reusing Hana's CMakeLists.txt? 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.

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.

Louis
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Follow-up to the follow-up of the CMake follow-up

Boost - Dev mailing list
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.



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