Boost logo

Boost :

Subject: Re: [boost] cmake target and binary name mangling
From: Florent Castelli (florent.castelli_at_[hidden])
Date: 2017-07-24 10:42:54


On 24/07/2017 01:19, P F via Boost wrote:
>> On Jul 23, 2017, at 5:42 AM, Niall Douglas via Boost <boost_at_[hidden]> 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_at_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>_<hl|sl|dl>-<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_ID>-$(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}-$<PLATFORM_ID>-${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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk