Re: [boost] cmake target and binary name mangling

24 Jul 2017

      On 24/07/2017 01:19, P F via Boost wrote:
...
...
On Jul 23, 2017, at 5:42 AM, Niall Douglas via Boost  wrote:
...
...
As I already mentioned in another post, specifying the entire
configuration in the target name is exactly the right way to implement
modern cmake 3.
Wouldn't this, if taken to its logical conclusion, amount to a (poor?)
reimplementation of Boost.Build in CMake? I mean, once you have
target-<variant>debug-<link>static that's pretty much what it is.
Why fix something that's broke? Closely replicating the Boost.Build
design will make replacing Boost.Build with cmake so much easier. All
the dependent tooling etc will "just work".
Besides, John Maddock is 100% right that ABI requirements ought to be
encoded into the shared library name. Saves so much time and hassle and
confusion, plus consumers can easily REGEX out the link requirements if
needed.
Here are the cmake targets which my quickcpplib tooling autogenerates
for AFIO v2 based on inspection of the environment (apologies for the
long list in advance):
```
ned@lyta:~/windocs/boostish/afio/build_posix$ make help | sort
... afio-asan
... afio_dl
... afio_dl-asan
... afio_dl-asan-atuple
... afio_dl-asan-coverage_main
... afio_dl-asan-execinfo_win64
... afio_dl-asan-file_handle_create_close
... afio_dl-asan-file_handle_lock_unlock
... afio_dl-asan-map_handle_create_close
... afio_dl-asan-open_hash_index
... afio_dl-asan-packed_backtrace
... afio_dl-asan-ringbuffer_log
... afio_dl-asan-section_handle_create_close
... afio_dl-asan-shared_fs_mutex
... afio_dl-asan-spinlock_tribool
... afio_dl-asan-test_guard
... afio_dl-asan-test_import
... afio_dl-asan-test_message
... afio_dl-asan-type_traits
... afio_dl--atuple
... afio_dl--coverage_main
... afio_dl--execinfo_win64
... afio_dl--file_handle_create_close
... afio_dl--file_handle_lock_unlock
... afio_dl--map_handle_create_close
... afio_dl-msan
... afio_dl-msan-atuple
... afio_dl-msan-coverage_main
... afio_dl-msan-execinfo_win64
... afio_dl-msan-file_handle_create_close
... afio_dl-msan-file_handle_lock_unlock
... afio_dl-msan-map_handle_create_close
... afio_dl-msan-open_hash_index
... afio_dl-msan-packed_backtrace
... afio_dl-msan-ringbuffer_log
... afio_dl-msan-section_handle_create_close
... afio_dl-msan-shared_fs_mutex
... afio_dl-msan-spinlock_tribool
... afio_dl-msan-test_guard
... afio_dl-msan-test_import
... afio_dl-msan-test_message
... afio_dl-msan-type_traits
... afio_dl--open_hash_index
... afio_dl--packed_backtrace
... afio_dl--ringbuffer_log
... afio_dl--section_handle_create_close
... afio_dl--shared_fs_mutex
... afio_dl--spinlock_tribool
... afio_dl--test_guard
... afio_dl--test_import
... afio_dl--test_message
... afio_dl-tsan
... afio_dl-tsan-atuple
... afio_dl-tsan-coverage_main
... afio_dl-tsan-execinfo_win64
... afio_dl-tsan-file_handle_create_close
... afio_dl-tsan-file_handle_lock_unlock
... afio_dl-tsan-map_handle_create_close
... afio_dl-tsan-open_hash_index
... afio_dl-tsan-packed_backtrace
... afio_dl-tsan-ringbuffer_log
... afio_dl-tsan-section_handle_create_close
... afio_dl-tsan-shared_fs_mutex
... afio_dl-tsan-spinlock_tribool
... afio_dl-tsan-test_guard
... afio_dl-tsan-test_import
... afio_dl-tsan-test_message
... afio_dl-tsan-type_traits
... afio_dl--type_traits
... afio_dl-ubsan
... afio_dl-ubsan-atuple
... afio_dl-ubsan-coverage_main
... afio_dl-ubsan-execinfo_win64
... afio_dl-ubsan-file_handle_create_close
... afio_dl-ubsan-file_handle_lock_unlock
... afio_dl-ubsan-map_handle_create_close
... afio_dl-ubsan-open_hash_index
... afio_dl-ubsan-packed_backtrace
... afio_dl-ubsan-ringbuffer_log
... afio_dl-ubsan-section_handle_create_close
... afio_dl-ubsan-shared_fs_mutex
... afio_dl-ubsan-spinlock_tribool
... afio_dl-ubsan-test_guard
... afio_dl-ubsan-test_import
... afio_dl-ubsan-test_message
... afio_dl-ubsan-type_traits
... afio_docs
... afio_hl-asan-atuple
... afio_hl-asan-coverage_main
... afio_hl-asan-execinfo_win64
... afio_hl-asan-file_handle_create_close
... afio_hl-asan-file_handle_lock_unlock
... afio_hl-asan-map_handle_create_close
... afio_hl-asan-open_hash_index
... afio_hl-asan-packed_backtrace
... afio_hl-asan-ringbuffer_log
... afio_hl-asan-section_handle_create_close
... afio_hl-asan-shared_fs_mutex
... afio_hl-asan-spinlock_tribool
... afio_hl-asan-test_guard
... afio_hl-asan-test_import
... afio_hl-asan-test_message
... afio_hl-asan-type_traits
... afio_hl--atuple
... afio_hl--coverage_main
... afio_hl--execinfo_win64
... afio_hl--file_handle_create_close
... afio_hl--file_handle_lock_unlock
... afio_hl--map_handle_create_close
... afio_hl-msan-atuple
... afio_hl-msan-coverage_main
... afio_hl-msan-execinfo_win64
... afio_hl-msan-file_handle_create_close
... afio_hl-msan-file_handle_lock_unlock
... afio_hl-msan-map_handle_create_close
... afio_hl-msan-open_hash_index
... afio_hl-msan-packed_backtrace
... afio_hl-msan-ringbuffer_log
... afio_hl-msan-section_handle_create_close
... afio_hl-msan-shared_fs_mutex
... afio_hl-msan-spinlock_tribool
... afio_hl-msan-test_guard
... afio_hl-msan-test_import
... afio_hl-msan-test_message
... afio_hl-msan-type_traits
... afio_hl--open_hash_index
... afio_hl--packed_backtrace
... afio_hl--ringbuffer_log
... afio_hl--section_handle_create_close
... afio_hl--shared_fs_mutex
... afio_hl--spinlock_tribool
... afio_hl--test_guard
... afio_hl--test_import
... afio_hl--test_message
... afio_hl-tsan-atuple
... afio_hl-tsan-coverage_main
... afio_hl-tsan-execinfo_win64
... afio_hl-tsan-file_handle_create_close
... afio_hl-tsan-file_handle_lock_unlock
... afio_hl-tsan-map_handle_create_close
... afio_hl-tsan-open_hash_index
... afio_hl-tsan-packed_backtrace
... afio_hl-tsan-ringbuffer_log
... afio_hl-tsan-section_handle_create_close
... afio_hl-tsan-shared_fs_mutex
... afio_hl-tsan-spinlock_tribool
... afio_hl-tsan-test_guard
... afio_hl-tsan-test_import
... afio_hl-tsan-test_message
... afio_hl-tsan-type_traits
... afio_hl--type_traits
... afio_hl-ubsan-atuple
... afio_hl-ubsan-coverage_main
... afio_hl-ubsan-execinfo_win64
... afio_hl-ubsan-file_handle_create_close
... afio_hl-ubsan-file_handle_lock_unlock
... afio_hl-ubsan-map_handle_create_close
... afio_hl-ubsan-open_hash_index
... afio_hl-ubsan-packed_backtrace
... afio_hl-ubsan-ringbuffer_log
... afio_hl-ubsan-section_handle_create_close
... afio_hl-ubsan-shared_fs_mutex
... afio_hl-ubsan-spinlock_tribool
... afio_hl-ubsan-test_guard
... afio_hl-ubsan-test_import
... afio_hl-ubsan-test_message
... afio_hl-ubsan-type_traits
... afio-msan
... afio_sl
... afio_sl-asan
... afio_sl-asan-atuple
... afio_sl-asan-coverage_main
... afio_sl-asan-execinfo_win64
... afio_sl-asan-file_handle_create_close
... afio_sl-asan-file_handle_lock_unlock
... afio_sl-asan-map_handle_create_close
... afio_sl-asan-open_hash_index
... afio_sl-asan-packed_backtrace
... afio_sl-asan-ringbuffer_log
... afio_sl-asan-section_handle_create_close
... afio_sl-asan-shared_fs_mutex
... afio_sl-asan-spinlock_tribool
... afio_sl-asan-test_guard
... afio_sl-asan-test_import
... afio_sl-asan-test_message
... afio_sl-asan-type_traits
... afio_sl--atuple
... afio_sl--coverage_main
... afio_sl--execinfo_win64
... afio_sl--file_handle_create_close
... afio_sl--file_handle_lock_unlock
... afio_sl--map_handle_create_close
... afio_sl-msan
... afio_sl-msan-atuple
... afio_sl-msan-coverage_main
... afio_sl-msan-execinfo_win64
... afio_sl-msan-file_handle_create_close
... afio_sl-msan-file_handle_lock_unlock
... afio_sl-msan-map_handle_create_close
... afio_sl-msan-open_hash_index
... afio_sl-msan-packed_backtrace
... afio_sl-msan-ringbuffer_log
... afio_sl-msan-section_handle_create_close
... afio_sl-msan-shared_fs_mutex
... afio_sl-msan-spinlock_tribool
... afio_sl-msan-test_guard
... afio_sl-msan-test_import
... afio_sl-msan-test_message
... afio_sl-msan-type_traits
... afio_sl--open_hash_index
... afio_sl--packed_backtrace
... afio_sl--ringbuffer_log
... afio_sl--section_handle_create_close
... afio_sl--shared_fs_mutex
... afio_sl--spinlock_tribool
... afio_sl--test_guard
... afio_sl--test_import
... afio_sl--test_message
... afio_sl-tsan
... afio_sl-tsan-atuple
... afio_sl-tsan-coverage_main
... afio_sl-tsan-execinfo_win64
... afio_sl-tsan-file_handle_create_close
... afio_sl-tsan-file_handle_lock_unlock
... afio_sl-tsan-map_handle_create_close
... afio_sl-tsan-open_hash_index
... afio_sl-tsan-packed_backtrace
... afio_sl-tsan-ringbuffer_log
... afio_sl-tsan-section_handle_create_close
... afio_sl-tsan-shared_fs_mutex
... afio_sl-tsan-spinlock_tribool
... afio_sl-tsan-test_guard
... afio_sl-tsan-test_import
... afio_sl-tsan-test_message
... afio_sl-tsan-type_traits
... afio_sl--type_traits
... afio_sl-ubsan
... afio_sl-ubsan-atuple
... afio_sl-ubsan-coverage_main
... afio_sl-ubsan-execinfo_win64
... afio_sl-ubsan-file_handle_create_close
... afio_sl-ubsan-file_handle_lock_unlock
... afio_sl-ubsan-map_handle_create_close
... afio_sl-ubsan-open_hash_index
... afio_sl-ubsan-packed_backtrace
... afio_sl-ubsan-ringbuffer_log
... afio_sl-ubsan-section_handle_create_close
... afio_sl-ubsan-shared_fs_mutex
... afio_sl-ubsan-spinlock_tribool
... afio_sl-ubsan-test_guard
... afio_sl-ubsan-test_import
... afio_sl-ubsan-test_message
... afio_sl-ubsan-type_traits
... afio-tsan
... afio-ubsan
... all (the default if no target is provided)
... _asan
... clean
... Continuous
... ContinuousBuild
... ContinuousConfigure
... ContinuousCoverage
... ContinuousMemCheck
... ContinuousStart
... ContinuousSubmit
... ContinuousTest
... ContinuousUpdate
... depend
... _dl
... _docs
... edit_cache
... Experimental
... ExperimentalBuild
... ExperimentalConfigure
... ExperimentalCoverage
... ExperimentalMemCheck
... ExperimentalStart
... ExperimentalSubmit
... ExperimentalTest
... ExperimentalUpdate
... _hl
... install
... install/local
... install/strip
... kerneltest_docs
... list_install_components
... _msan
... Nightly
... NightlyBuild
... NightlyConfigure
... NightlyCoverage
... NightlyMemCheck
... NightlyMemoryCheck
... NightlyStart
... NightlySubmit
... NightlyTest
... NightlyUpdate
... quickcpplib_docs
... rebuild_cache
... _sl
The following are some of the valid targets for this Makefile:
... _tsan
... _ubsan
```
The target graphs are REGEXable via the pattern
"<lib>_-<special>-<binary>" where:
* hl = header only library
* sl = static library
* dl = shared library
There is no need for `hl` as it doesn’t produce binaries.
"hl" is necessary as a CMake logical target, not at as a build output.
The problem I have with all those targets, is that they add a lot of 
overload to IDE solutions who will scan sources for every configuration 
and for people whose workflow is to build "all" or the whole solution 
for MSVC, which will build way too many versions.
...
...
... and <special> is anything affecting the link requirements of the
binary, so here QuickCppLib auto detected the code sanitisers
asan,msan,tsan,ubsan all of which require to be linked like-with-like,
and hence needed a separate <special> category.
Group-level targets also exist, so "afio_sl-tsan" means "all the static
library AFIO targets with Thread Sanitiser", "_tsan" means "all the
targets with Thread Sanitiser" and so on.
Almost the entire graph above is marked with EXCLUDE_FROM_ALL, so it is
NOT built unless you specifically request it at the command line.
The above is just the mangling for cmake targets which must always be
unique within a given cmake build else cmake will refuse to work, hence
mangling systematically according to a strict REGEX pattern makes a ton
of sense (and using TARGET ALIAS to a more convenient to type target
name like "boost::afio").
The actual binaries generated by the build are further mangled again
according to this REGEXable pattern:
```
if(CMAKE_GENERATOR MATCHES "Visual Studio")
  set_target_properties(${PROJECT_NAME}_dl PROPERTIES
    OUTPUT_NAME
"${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$-$(Platform)-$<CONFIG>"
  )
elseif(CMAKE_GENERATOR MATCHES "Xcode")
  set_target_properties(${PROJECT_NAME}_dl PROPERTIES
    OUTPUT_NAME
"${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$-${CMAKE_SYSTEM_PROCESSOR}-$<CONFIG>"
  )
else()
  set_target_properties(${PROJECT_NAME}_dl PROPERTIES
    OUTPUT_NAME
"${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_PROCESSOR}-${CMAKE_BUILD_TYPE}"
  )
endif()
```
We could definitely encode this information from the build into the name, but it should be an option like it is now. Perhaps when building with `-DLAYOUT=tagged` will get this behavior. Of course, all this will require custom functions from our own cmake module to make sure this is consistent across boost libraries.
I think this is the proper middle ground between both approaches and 
should totally be doable. In order to reduce boilerplate across all 
libraries, some common support code needs to be added anyway.
As for which one should be default, that's I guess another whole 
discussion (which is kind of moot when using "add_subdirectory()" 
integration for example).

Though, I disagree with the example above, there's no need to separate 
all the platforms. The Visual Studio generators don't support multiple 
archs (Intel 32, 64 and ARM) together, so no "$(Platform)" needed.
On Darwin, CMAKE_SYSTEM_PROCESSOR is a bit unreliable too if you 
consider universal builds on the platforms (ppc + i386 + x86_64). For 
other generators, you should use the generator expressions too.
...
...
This will generate library binaries of the pattern:
afio_dl-2.0-Linux-x64-Release.so
afio_dl-2.0-FreeBSD-x64-MinSizeRel.so
afio_dl-2.0-Win32-x86-RelWithDebInfo.dll
... and so on, correctly handling if the user selects different build
configs in Visual Studio or XCode which cmake doesn't know anything about.
Only when you link against the library using this pattern, which is really only necessary when not using cmake.
...
So, all in all, very like Boost.Build currently does. And that's because
it's the correct design and approach to take. So we should do that in
any cmake of Boost too.
The issue isn’t that we encode build information into the name. Its that cmake doesn’t handle multiple variants in the same build tree, like what boost build does. Cmake could support this as it supports multiple configurations with IDEs like VS or XCode. This could be extended to all build systems. Until then, I think building a frontend for cmake that can automate the multiple build trees would be useful to users of b2.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] cmake target and binary name mangling

Florent Castelli