URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=3db32bcb5d6ab7bd1e154cdbb0528d0f6d647c9f
Submitter: "Anders Broman <a.broman58@xxxxxxxxx>"
Changed: branch: master
Repository: wireshark
Commits:
3db32bc by Guy Harris (guy@xxxxxxxxxxxx):
Revert "Use CMAKE_EXE_LINKER_FLAGS to set link flags on executables."
This reverts commit 84447550efdad68acfc69281750ed016f7f96716.
Reason for revert: CMake's documentation for the flags variables is
close to content-free, giving no indication what the link flags used
in the link will be, given a combination of various CMAKE.*LINKER_FLAGS
variables and LINK_FLAGS properties. That makes it extremely difficult
to determine why this change happens to cause some executables to
be linked with "/INCREMENTAL" and others to be linked with
"/INCREMENTAL:YES", even though we add "/INCREMENTAL:NO" to
WS_LINK_FLAGS and add WS_LINK_FLAGS to CMAKE_EXE_LINKER_FLAGS - or
why *not* setting CMAKE_EXE_LINKER_FLAGS and instead using LINK_FLAGS
*doesn't* cause that to happen.
Maybe it's an issue of CMAKE_EXE_LINKER_FLAGS vs.
CMAKE_EXE_LINKER_FLAGS_<CONFIG>, but the documentation doesn't
clearly indicate whether, for example, the link flags for a particular
executable target are a combination of CMAKE_EXE_LINKER_FLAGS, the
CMAKE_EXE_LINKER_FLAGS_<CONFIG> flag for the configuration of this
build, and the LINK_FLAGS property of the target, if any. That's
the most *obvious* behavior to implement, but if that's the behavior
that's implemented, I'm not sure why the change being reverted had the
effect it did.
Change-Id: I6a73fe88be65378d506a89460f7362076233f319
Reviewed-on: https://code.wireshark.org/review/30023
Petri-Dish: Guy Harris <guy@xxxxxxxxxxxx>
Reviewed-by: Guy Harris <guy@xxxxxxxxxxxx>
Tested-by: Petri Dish Buildbot
Actions performed:
from ebcc4eb ieee80211: register some etts.
add 3db32bc Revert "Use CMAKE_EXE_LINKER_FLAGS to set link flags on executables."
Summary of changes:
CMakeLists.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)