2017-04-11 21:45:05 +08:00
|
|
|
if (COMPILER_RT_BUILD_SANITIZERS)
|
|
|
|
|
set(SANITIZER_HEADERS
|
|
|
|
|
sanitizer/allocator_interface.h
|
|
|
|
|
sanitizer/asan_interface.h
|
|
|
|
|
sanitizer/common_interface_defs.h
|
|
|
|
|
sanitizer/coverage_interface.h
|
|
|
|
|
sanitizer/dfsan_interface.h
|
2017-12-09 09:31:51 +08:00
|
|
|
sanitizer/hwasan_interface.h
|
2017-04-11 21:45:05 +08:00
|
|
|
sanitizer/linux_syscall_hooks.h
|
|
|
|
|
sanitizer/lsan_interface.h
|
|
|
|
|
sanitizer/msan_interface.h
|
Add NetBSD syscall hooks skeleton in sanitizers
Summary:
Implement the skeleton of NetBSD syscall hooks for use with sanitizers.
Add a script that generates the rules to handle syscalls
on NetBSD: generate_netbsd_syscalls.awk. It has been written
in NetBSD awk(1) (patched nawk) and is compatible with gawk.
Generate lib/sanitizer_common/sanitizer_platform_limits_netbsd.h
that is a public header for applications, and included as:
<sanitizer_common/sanitizer_platform_limits_netbsd.h>.
Generate sanitizer_syscalls_netbsd.inc that defines all the
syscall rules for NetBSD. This file is modeled after the Linux
specific file: sanitizer_common_syscalls.inc.
Start recognizing NetBSD syscalls with existing sanitizers:
ASan, ESan, HWASan, TSan, MSan.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, vitalybuka, kcc, dvyukov, eugenis
Reviewed By: vitalybuka
Subscribers: hintonda, kubamracek, mgorny, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D42048
llvm-svn: 325206
2018-02-15 10:43:02 +08:00
|
|
|
sanitizer/netbsd_syscall_hooks.h
|
2017-12-14 04:41:35 +08:00
|
|
|
sanitizer/scudo_interface.h
|
2017-04-11 21:45:05 +08:00
|
|
|
sanitizer/tsan_interface.h
|
2019-01-17 02:12:45 +08:00
|
|
|
sanitizer/tsan_interface_atomic.h
|
2019-09-13 16:22:58 +08:00
|
|
|
sanitizer/ubsan_interface.h
|
2019-01-17 02:12:45 +08:00
|
|
|
)
|
[compiler-rt] Move FDP to include/fuzzer/FuzzedDataProvider.h for easier use.
Summary:
FuzzedDataProvider is a helper class for writing fuzz targets that fuzz
multple inputs simultaneously. The header is supposed to be used for fuzzing
engine agnostic fuzz targets (i.e. the same target can be used with libFuzzer,
AFL, honggfuzz, and other engines). The common thing though is that fuzz targets
are typically compiled with clang, as it provides all sanitizers as well as
different coverage instrumentation modes. Therefore, making this FDP class a
part of the compiler-rt installation package would make it easier to develop
and distribute fuzz targets across different projects, build systems, etc.
Some context also available in https://github.com/google/oss-fuzz/pull/2547.
This CL does not delete the header from `lib/fuzzer/utils` directory in order to
provide the downstream users some time for a smooth migration to the new
header location.
Reviewers: kcc, morehouse
Reviewed By: morehouse
Subscribers: lebedev.ri, kubamracek, dberris, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65661
llvm-svn: 367917
2019-08-06 03:55:52 +08:00
|
|
|
set(FUZZER_HEADERS
|
[compiler-rt] Add ConsumeProbability and ConsumeFloatingPoint methods to FDP.
Summary:
Also slightly cleaned up the comments and changed the header's extension
back to `.h` as per comments on https://reviews.llvm.org/D65812.
New methods added:
* `ConsumeProbability` returns [0.0, 1.0] by consuming an unsigned integer value
from the input data and dividing that value by the integer's max value.
* `ConsumeFloatingPointInRange` returns a floating point value in the given
range. Relies on `ConsumeProbability` method. This method does not have the
limitation of `std::uniform_real_distribution` that requires the given range
to be <= the floating point type's max. If the range is too large, this
implementation will additionally call `ConsumeBool` to decide whether the
result will be in the first or the second half of the range.
* `ConsumeFloatingPoint` returns a floating point value in the range
`[std::numeric_limits<T>::lowest(), std::numeric_limits<T>::min()]`.
Tested on Linux, Mac, Windows.
Reviewers: morehouse
Reviewed By: morehouse
Subscribers: kubamracek, mgorny, dberris, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65905
llvm-svn: 368331
2019-08-09 03:49:37 +08:00
|
|
|
fuzzer/FuzzedDataProvider.h
|
[compiler-rt] Move FDP to include/fuzzer/FuzzedDataProvider.h for easier use.
Summary:
FuzzedDataProvider is a helper class for writing fuzz targets that fuzz
multple inputs simultaneously. The header is supposed to be used for fuzzing
engine agnostic fuzz targets (i.e. the same target can be used with libFuzzer,
AFL, honggfuzz, and other engines). The common thing though is that fuzz targets
are typically compiled with clang, as it provides all sanitizers as well as
different coverage instrumentation modes. Therefore, making this FDP class a
part of the compiler-rt installation package would make it easier to develop
and distribute fuzz targets across different projects, build systems, etc.
Some context also available in https://github.com/google/oss-fuzz/pull/2547.
This CL does not delete the header from `lib/fuzzer/utils` directory in order to
provide the downstream users some time for a smooth migration to the new
header location.
Reviewers: kcc, morehouse
Reviewed By: morehouse
Subscribers: lebedev.ri, kubamracek, dberris, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65661
llvm-svn: 367917
2019-08-06 03:55:52 +08:00
|
|
|
)
|
2017-04-11 21:45:05 +08:00
|
|
|
endif(COMPILER_RT_BUILD_SANITIZERS)
|
2013-04-11 23:49:52 +08:00
|
|
|
|
2020-10-27 04:36:01 +08:00
|
|
|
if (COMPILER_RT_BUILD_MEMPROF)
|
|
|
|
|
set(MEMPROF_HEADERS
|
|
|
|
|
sanitizer/memprof_interface.h
|
2021-11-20 06:02:41 +08:00
|
|
|
profile/MemProfData.inc
|
2020-10-27 04:36:01 +08:00
|
|
|
)
|
|
|
|
|
endif(COMPILER_RT_BUILD_MEMPROF)
|
|
|
|
|
|
2017-04-11 21:45:05 +08:00
|
|
|
if (COMPILER_RT_BUILD_XRAY)
|
|
|
|
|
set(XRAY_HEADERS
|
|
|
|
|
xray/xray_interface.h
|
2019-01-17 02:12:45 +08:00
|
|
|
xray/xray_log_interface.h
|
2019-01-18 05:11:49 +08:00
|
|
|
xray/xray_records.h
|
2019-01-17 02:12:45 +08:00
|
|
|
)
|
2017-04-11 21:45:05 +08:00
|
|
|
endif(COMPILER_RT_BUILD_XRAY)
|
2016-07-21 15:39:55 +08:00
|
|
|
|
2022-06-17 09:31:29 +08:00
|
|
|
if (COMPILER_RT_BUILD_ORC)
|
|
|
|
|
set(ORC_HEADERS
|
|
|
|
|
orc/c_api.h
|
|
|
|
|
)
|
|
|
|
|
endif(COMPILER_RT_BUILD_ORC)
|
|
|
|
|
|
2019-11-23 04:09:15 +08:00
|
|
|
if (COMPILER_RT_BUILD_PROFILE)
|
|
|
|
|
set(PROFILE_HEADERS
|
|
|
|
|
profile/InstrProfData.inc
|
|
|
|
|
)
|
|
|
|
|
endif(COMPILER_RT_BUILD_PROFILE)
|
|
|
|
|
|
2016-07-21 15:39:55 +08:00
|
|
|
set(COMPILER_RT_HEADERS
|
|
|
|
|
${SANITIZER_HEADERS}
|
[compiler-rt] Move FDP to include/fuzzer/FuzzedDataProvider.h for easier use.
Summary:
FuzzedDataProvider is a helper class for writing fuzz targets that fuzz
multple inputs simultaneously. The header is supposed to be used for fuzzing
engine agnostic fuzz targets (i.e. the same target can be used with libFuzzer,
AFL, honggfuzz, and other engines). The common thing though is that fuzz targets
are typically compiled with clang, as it provides all sanitizers as well as
different coverage instrumentation modes. Therefore, making this FDP class a
part of the compiler-rt installation package would make it easier to develop
and distribute fuzz targets across different projects, build systems, etc.
Some context also available in https://github.com/google/oss-fuzz/pull/2547.
This CL does not delete the header from `lib/fuzzer/utils` directory in order to
provide the downstream users some time for a smooth migration to the new
header location.
Reviewers: kcc, morehouse
Reviewed By: morehouse
Subscribers: lebedev.ri, kubamracek, dberris, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65661
llvm-svn: 367917
2019-08-06 03:55:52 +08:00
|
|
|
${FUZZER_HEADERS}
|
2020-10-27 04:36:01 +08:00
|
|
|
${MEMPROF_HEADERS}
|
2019-11-23 04:09:15 +08:00
|
|
|
${XRAY_HEADERS}
|
2022-06-17 09:31:29 +08:00
|
|
|
${ORC_HEADERS}
|
2019-11-23 04:09:15 +08:00
|
|
|
${PROFILE_HEADERS})
|
2016-07-21 15:39:55 +08:00
|
|
|
|
2014-02-18 22:28:53 +08:00
|
|
|
set(output_dir ${COMPILER_RT_OUTPUT_DIR}/include)
|
2013-04-11 23:49:52 +08:00
|
|
|
|
|
|
|
|
# Copy compiler-rt headers to the build tree.
|
|
|
|
|
set(out_files)
|
2016-07-21 15:39:55 +08:00
|
|
|
foreach( f ${COMPILER_RT_HEADERS} )
|
2013-04-11 23:49:52 +08:00
|
|
|
set( src ${CMAKE_CURRENT_SOURCE_DIR}/${f} )
|
|
|
|
|
set( dst ${output_dir}/${f} )
|
|
|
|
|
add_custom_command(OUTPUT ${dst}
|
|
|
|
|
DEPENDS ${src}
|
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${src} ${dst}
|
|
|
|
|
COMMENT "Copying compiler-rt's ${f}...")
|
|
|
|
|
list(APPEND out_files ${dst})
|
|
|
|
|
endforeach( f )
|
|
|
|
|
|
|
|
|
|
add_custom_target(compiler-rt-headers ALL DEPENDS ${out_files})
|
2013-11-18 18:57:36 +08:00
|
|
|
add_dependencies(compiler-rt compiler-rt-headers)
|
2016-07-12 05:51:56 +08:00
|
|
|
set_target_properties(compiler-rt-headers PROPERTIES FOLDER "Compiler-RT Misc")
|
2013-04-11 23:49:52 +08:00
|
|
|
|
|
|
|
|
# Install sanitizer headers.
|
|
|
|
|
install(FILES ${SANITIZER_HEADERS}
|
2017-12-15 21:20:13 +08:00
|
|
|
COMPONENT compiler-rt-headers
|
2013-04-11 23:49:52 +08:00
|
|
|
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
|
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all
This is a second attempt at D101497, which landed as
9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in
8cf7ddbdd4e5af966a369e170c73250f2e3920e7.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
|
|
|
DESTINATION ${COMPILER_RT_INSTALL_INCLUDE_DIR}/sanitizer)
|
[compiler-rt] Move FDP to include/fuzzer/FuzzedDataProvider.h for easier use.
Summary:
FuzzedDataProvider is a helper class for writing fuzz targets that fuzz
multple inputs simultaneously. The header is supposed to be used for fuzzing
engine agnostic fuzz targets (i.e. the same target can be used with libFuzzer,
AFL, honggfuzz, and other engines). The common thing though is that fuzz targets
are typically compiled with clang, as it provides all sanitizers as well as
different coverage instrumentation modes. Therefore, making this FDP class a
part of the compiler-rt installation package would make it easier to develop
and distribute fuzz targets across different projects, build systems, etc.
Some context also available in https://github.com/google/oss-fuzz/pull/2547.
This CL does not delete the header from `lib/fuzzer/utils` directory in order to
provide the downstream users some time for a smooth migration to the new
header location.
Reviewers: kcc, morehouse
Reviewed By: morehouse
Subscribers: lebedev.ri, kubamracek, dberris, mgorny, delcypher, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D65661
llvm-svn: 367917
2019-08-06 03:55:52 +08:00
|
|
|
# Install fuzzer headers.
|
|
|
|
|
install(FILES ${FUZZER_HEADERS}
|
|
|
|
|
COMPONENT compiler-rt-headers
|
|
|
|
|
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
|
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all
This is a second attempt at D101497, which landed as
9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in
8cf7ddbdd4e5af966a369e170c73250f2e3920e7.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
|
|
|
DESTINATION ${COMPILER_RT_INSTALL_INCLUDE_DIR}/fuzzer)
|
2016-07-21 15:39:55 +08:00
|
|
|
# Install xray headers.
|
|
|
|
|
install(FILES ${XRAY_HEADERS}
|
2017-12-15 21:20:13 +08:00
|
|
|
COMPONENT compiler-rt-headers
|
2016-07-21 15:39:55 +08:00
|
|
|
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
|
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all
This is a second attempt at D101497, which landed as
9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in
8cf7ddbdd4e5af966a369e170c73250f2e3920e7.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
|
|
|
DESTINATION ${COMPILER_RT_INSTALL_INCLUDE_DIR}/xray)
|
2022-06-17 09:31:29 +08:00
|
|
|
# Install ORC headers.
|
|
|
|
|
install(FILES ${ORC_HEADERS}
|
|
|
|
|
COMPONENT compiler-rt-headers
|
|
|
|
|
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
|
|
|
|
|
DESTINATION ${COMPILER_RT_INSTALL_INCLUDE_DIR}/orc)
|
2019-11-23 04:09:15 +08:00
|
|
|
# Install profile headers.
|
|
|
|
|
install(FILES ${PROFILE_HEADERS}
|
|
|
|
|
COMPONENT compiler-rt-headers
|
|
|
|
|
PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
|
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all
This is a second attempt at D101497, which landed as
9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in
8cf7ddbdd4e5af966a369e170c73250f2e3920e7.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
2021-04-29 06:36:47 +08:00
|
|
|
DESTINATION ${COMPILER_RT_INSTALL_INCLUDE_DIR}/profile)
|
2017-12-15 21:20:13 +08:00
|
|
|
|
|
|
|
|
if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDEs.
|
|
|
|
|
add_custom_target(install-compiler-rt-headers
|
|
|
|
|
DEPENDS compiler-rt-headers
|
|
|
|
|
COMMAND "${CMAKE_COMMAND}"
|
|
|
|
|
-DCMAKE_INSTALL_COMPONENT="compiler-rt-headers"
|
|
|
|
|
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake"
|
|
|
|
|
USES_TERMINAL)
|
|
|
|
|
add_custom_target(install-compiler-rt-headers-stripped
|
|
|
|
|
DEPENDS compiler-rt-headers
|
|
|
|
|
COMMAND "${CMAKE_COMMAND}"
|
|
|
|
|
-DCMAKE_INSTALL_COMPONENT="compiler-rt-headers"
|
|
|
|
|
-DCMAKE_INSTALL_DO_STRIP=1
|
|
|
|
|
-P "${CMAKE_BINARY_DIR}/cmake_install.cmake"
|
|
|
|
|
USES_TERMINAL)
|
|
|
|
|
endif()
|