taglib: opportunistically links with boost

[ctreleaven (Craig Treleaven)]

$ port installed taglib boost
The following ports are currently installed:
  boost @1.58.0_3+no_single+no_static+python27
  boost @1.59.0_2+no_single+no_static+python27 (active)
  taglib @1.9.1_0
  taglib @1.11_1
  taglib @1.11.1_0 (active)

$ otool -L /opt/local/lib/libtag.1.dylib
/opt/local/lib/libtag.1.dylib:
	/opt/local/lib/libtag.1.dylib (compatibility version 1.0.0, current version 1.17.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/opt/local/lib/libboost_atomic-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

I don't know enough about cmake to tell if a configure flag can eliminate this behaviour.

[ctreleaven (Craig Treleaven)]

I may have found a solution. It appears that appending -DBoost_INCLUDE_DIR="" to the configure args prevents an installed boost from being found. Not the cleanest solution but the resulting lib no longer references libboost_atomic-mt.dylib.

Relevant portion of the configure output is:

-- Could NOT find Boost
-- Performing Test HAVE_STD_ATOMIC
-- Performing Test HAVE_STD_ATOMIC - Failed
CMake Warning at /opt/local/share/cmake-3.7/Modules/FindBoost.cmake:761 (message):
  Imported targets not available for Boost version
Call Stack (most recent call first):
  /opt/local/share/cmake-3.7/Modules/FindBoost.cmake:865 (_Boost_COMPONENT_DEPENDENCIES)
  /opt/local/share/cmake-3.7/Modules/FindBoost.cmake:1454 (_Boost_MISSING_DEPENDENCIES)
  ConfigureChecks.cmake:57 (find_package)
  CMakeLists.txt:101 (include)


-- Could NOT find Boost
-- Performing Test HAVE_GCC_ATOMIC
-- Performing Test HAVE_GCC_ATOMIC - Success
-- Performing Test HAVE_BOOST_BYTESWAP
-- Performing Test HAVE_BOOST_BYTESWAP - Success

I can commit this if you like.

[ctreleaven (Craig Treleaven)]

Attached patch fixes the opportunistic linking with boost as well as adding variants to perform unit tests and build example programs.

[ryandesign (Ryan Carsten Schmidt)]

Why does enabling tests require disabling shared libraries?

There shouldn't be a need to write ${workpath}/build; you should be able to write ${build.dir}.

Anyway, this seems unrelated to the matter at hand. Let's concentrate on just the opportunistic boost linking.

[ctreleaven (Craig Treleaven)]

Replying to ryandesign:

Why does enabling tests require disabling shared libraries?

See ​https://github.com/taglib/taglib/blob/master/CMakeLists.txt#L149

There shouldn't be a need to write ${workpath}/build; you should be able to write ${build.dir}.

Noted.

Anyway, this seems unrelated to the matter at hand. Let's concentrate on just the opportunistic boost linking.

I wanted to enable tests in case boost had any other impact. At that point, it was trivial to enable the examples.

[ryandesign (Ryan Carsten Schmidt)]

In 2f0e2f5362b3fe764f530b05676cce389fb01e53/macports-ports (master):

taglib: Add tests variant

See: #53452

[ryandesign (Ryan Carsten Schmidt)]

In ec344c606eddde65ca6782e90d78fdcfc78e0996/macports-ports (master):

taglib: Add examples variant

See: #53452

[ryandesign (Ryan Carsten Schmidt)]

In 66425c22bbbf376c62dc0bbae79dce240e1a3567/macports-ports (master):

taglib: Prevent boost from being used

Closes: #53452