Build fails with boost 1.71.0: server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make:84: *** target pattern contains no '%'. Stop.

[dvzrv]

I'm currently trying to rebuild supercollider against boost 1.71.0, but it fails:

make -f server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/depend
make[2]: Entering directory '/build/supercollider/src/supercollider-3.10.3/build'
server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make:84: *** target pattern contains no '%'.  Stop.
make[2]: Leaving directory '/build/supercollider/src/supercollider-3.10.3/build'
make[1]: *** [CMakeFiles/Makefile2:1380: server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/all] Error 2
make[1]: Leaving directory '/build/supercollider/src/supercollider-3.10.3/build'

Environment

• SuperCollider version: current develop HEAD (9f6bc367ba) (but also 3.10.3)
• Operating system: Arch Linux
• Other details (Qt version, audio driver, etc.):
  boost 1.71.0
  desktop-file-utils 0.24-1
  fftw 3.3.8-1
  link 3.0.2-1
  jack 0.125.0-7
  qt5-svg 5.13.1-1
  qt5-webengine 5.13.1-2
  qt5-websockets 5.13.1-1
  qt5-tools 5.13.1-1
  yaml-cpp 0.6.2-1
  cmake 3.15.3-1
  emacs 26.3-1
  gedit 3.34.0-1
  xorg-server-xvfb 1.20.5-2

Steps to reproduce

  mkdir -p build && cd build
  cmake .. -DCMAKE_INSTALL_PREFIX=/usr \
           -DCMAKE_BUILD_TYPE=Release \
           -DLIBSCSYNTH=ON \
           -DFORTIFY=ON \
           -DSYSTEM_YAMLCPP=ON \
           -DSYSTEM_BOOST=ON \
           -DSC_VIM=OFF
  make VERBOSE=1

Expected vs. actual behavior

Supercollider should compile with boost 1.71.0.
vs.
It fails:
supercollider-devel-build.log
supercollider-3.10.3-build.log

[mossheim]

Hey @dvzrv , a couple questions --

1. does this happen with a totally clean build?
2. any other targets that don't build? (i.e. with make -k)
3. what are the contents of server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make?

initial guess is that something wasn't quite right with #4185, and now the generated makefile is buggy with SYSTEM_BOOST

[dvzrv]

@brianlheim good point (about #4185). However, that's what I'm pulling in for 3.10.3 and what is used for develop HEAD and works with boost 1.69.0.

I'll provide you with the info asap, but to answer question 1 upfront: I'm building in a pristine container.

[dvzrv]

After rerun using make -k, I've also identified UIUgens, libscsynth and libsupernova and ran into #4490:
supercollider-3.10.3-build.log

To get back to the initial error, the accompanying line (83) in server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make looks like:

server/plugins/UIUGens_supernova.so: Boost::thread

build.make.txt

[dvzrv]

When comparing this to server/plugins/CMakeFiles/DiskIO_UGens_supernova.dir/build.make generated with boost 1.69.0, the difference becomes clear:

server/plugins/UIUGens_supernova.so: /usr/lib/libboost_thread.so

build.make.txt

So, yeah, the assessment, that something in #4185 might not apply cleanly anymore, seems correct.

Potentially the return of find_package() with newer boost is different, so that the following doesn't work the same?

add_library(boost_thread_lib SHARED IMPORTED)                                                                                                                                         
set_property(TARGET boost_thread_lib PROPERTY IMPORTED_LOCATION ${Boost_THREAD_LIBRARY})

Will investigate

[dvzrv]

It seems, that boost 1.71.0 ships its own cmake file, which takes precedence over cmake's own.
https://gitlab.kitware.com/cmake/cmake/merge_requests/3763

Running cmake with -DBoost_NO_BOOST_CMAKE=ON (to ignore the cmake files that come with boost) and applying #4491 I can compile 3.10.3!

I guess this means a follow up pull request, once the vendored boost of supercollider gets changed.

[mossheim]

Thanks for investigating @dvzrv !

It seems, that boost 1.71.0 ships its own cmake file, which takes precedence over cmake's own.

I see. But why should that cause problems here? Are the libraries it exports different somehow?

[dvzrv]

Are the libraries it exports different somehow?

The libraries (probably) not. However, the return values of find_package() are altered.
Once 1.71.0 is out of staging I can dive deeper into this and try to open a pull request for updating it for supercollider.

[mossheim]

i am currently unable to build because of mutual incompatibilities among Xcode, cmake, and boost, so i will be submitting a PR that i believe ought to fix this within a few days. I also have notes on what needs to be done in case anyone is interested.

[mossheim]

Closed in #4612