mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 19:50:14 +01:00
Jon Ross-Perkins
2f81858a36
string_view was suggested at https://github.com/carbon-language/carbon-lang/pull/5451#discussion_r2080640267, but it turns out it's helpful to be even more hermetic for build configuration.
31 lines
1.3 KiB
C++
31 lines
1.3 KiB
C++
// Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
|
// Exceptions. See /LICENSE for license information.
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
#ifndef CARBON_COMMON_BUILD_DATA_LINKSTAMP_H_
|
|
#define CARBON_COMMON_BUILD_DATA_LINKSTAMP_H_
|
|
|
|
namespace Carbon::BuildData::Internal {
|
|
|
|
// See build_data.h; the list of names here should match.
|
|
//
|
|
// Bazel will build dependencies on the `:build_data` library (which exposes
|
|
// `build_data_linkstamp.h`) throughout the build process, but
|
|
// `build_data_linkstamp.cpp` is compiled and linked per-binary -- essentially a
|
|
// separate library. In essence, `build_data_linkstamp.h` is exposing values
|
|
// that are assigned later (this has consequences like preventing `constexpr`
|
|
// use).
|
|
//
|
|
// Also, when build_data_linkstamp.cpp is compiled, this doesn't receive deps,
|
|
// so we can't use things like `llvm::StringRef` here. It should ideally be
|
|
// purely hermetic -- not even using STL for `string_view`. As a result, we use
|
|
// `build_data.h` as an intermediary to do a `StringRef` wrap.
|
|
extern const char platform[];
|
|
extern const bool build_coverage_enabled;
|
|
extern const char target_name[];
|
|
extern const char build_target[];
|
|
|
|
} // namespace Carbon::BuildData::Internal
|
|
|
|
#endif // CARBON_COMMON_BUILD_DATA_LINKSTAMP_H_
|