tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Boost cmake files



Hi there,

I got a user who has trouble building things using the pkgsrc prefix on
top of an Ubuntu Linux base system. The CMake-based build locates the
system Boost as it has this:

$ ls /usr/lib/x86_64-linux-gnu/cmake/ | grep -i boost
Boost-1.71.0
boost_atomic-1.71.0
boost_chrono-1.71.0
boost_date_time-1.71.0
BoostDetectToolset-1.71.0.cmake
boost_filesystem-1.71.0
boost_graph-1.71.0
boost_headers-1.71.0
boost_iostreams-1.71.0
boost_log-1.71.0
boost_log_setup-1.71.0
boost_math_c99-1.71.0
boost_math_c99f-1.71.0
boost_math_c99l-1.71.0
boost_math_tr1-1.71.0
boost_math_tr1f-1.71.0
boost_math_tr1l-1.71.0
boost_mpi-1.71.0
boost_mpi_python-1.71.0
boost_prg_exec_monitor-1.71.0
boost_program_options-1.71.0
boost_python-1.71.0
boost_random-1.71.0
boost_regex-1.71.0
boost_serialization-1.71.0
boost_system-1.71.0
boost_test_exec_monitor-1.71.0
boost_thread-1.71.0
boost_timer-1.71.0
boost_unit_test_framework-1.71.0
boost_wave-1.71.0
boost_wserialization-1.71.0

There are .cmake files in the various boost_*-1.71.0 sub-directories.

The pkgsrc install of Boost 1.78 here doesn't install any of those. The
result is that the user software build finds a mix of system cmake
files but pkgsrc Boost binaries, crashes and burns as a result.

So, I figure that we should install the CMake files for Boost. Or was
there a conscious decision to omit them? We got a number of packages
with some custom installation routine that just picks some files, not
what the Boost install would do by itself.

There is also some contention about which files to install with which
package. This could be a nuisance. I guess the general config part
comes with boost-headers. But what about py-boost?

/PREFIX/lib/cmake/boost_python-1.78.0
/PREFIX/lib/cmake/boost_python-1.78.0/boost_python-config.cmake
/PREFIX/lib/cmake/boost_python-1.78.0/boost_python-config-version.cmake
/PREFIX/lib/cmake/boost_python-1.78.0/libboost_python-variant-static-py3.8.cmake
/PREFIX/lib/cmake/boost_python-1.78.0/libboost_python-variant-shared-py3.8.cmake

It _seems_ like building with differing pythons will just add

	libboost_python-variant-{static,shared}-pyX.Y.cmake

and install identical -config.cmake and -config-version.cmake (why, oh,
why so many files for such simple things?). So should we have to make a
generic boost-python-cmake package?

The whole Boost thing (meta-pkgs/boost/) is rather special and I really
would like someone more intimate with it handle this. But lacking that,
some hints on how to avoid the obvious breakage and what direction is
desired would be nice.

Comments? Someone longing to just do this and spare me lots of pain? ;-)


Alrighty then,

Thomas

PS: I'd also like to live in a world where we wouldn't deal with all
that extra heap of CMake configuration files, big redundant scripts,
instead have some simple pkg-config modules and have also CMake use
those. But perhaps that won't work so nicely for those other platforms
that CMake became popular on.

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg


Home | Main Index | Thread Index | Old Index