maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/utils/bazel/llvm-project-overlay/llvm/cc_plugin_library.bzl

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

76 lines
3.0 KiB
Python
Raw Normal View History

Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
# This file is licensed under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
"""A macro to produce a loadable plugin library for the target OS.
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
This macro produces a set of platform-specific `cc_binary` rules, by appending
the platform suffix (`.dll`, `.dylib`, or `.so`) to the provided `name`. It then
connects these to a `cc_import` rule with `name` exactly and `hdrs` that can be
used by other Bazel rules to depend on the plugin library.
The `srcs` attribute for the `cc_binary` rules is `srcs + hdrs`. Other explicit
arguments are passed to all of the rules where they apply, and can be used to
configure generic aspects of all generated rules such as `testonly`. Lastly,
`kwargs` is expanded into all the `cc_binary` rules.
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
"""
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
load("@rules_cc//cc:defs.bzl", "cc_binary", "cc_import", "cc_library")
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
def cc_plugin_library(name, srcs, hdrs, include_prefix = None, strip_include_prefix = None, alwayslink = False, features = [], tags = [], testonly = False, **kwargs):
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
# Neither the name of the plugin binary nor tags on whether it is built are
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
# configurable. Instead, we build a `cc_binary` with each name and
# selectively depend on them based on platform.
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
#
# All-in-all, this is a pretty poor workaround. I think this is part of the
# Bazel issue: https://github.com/bazelbuild/bazel/issues/7538
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
so_name = name + ".so"
dll_name = name + ".dll"
dylib_name = name + ".dylib"
interface_output_name = name + "_interface_output"
import_name = name + "_import"
for impl_name in [dll_name, dylib_name, so_name]:
cc_binary(
name = impl_name,
srcs = srcs + hdrs,
linkshared = True,
linkstatic = True,
features = features,
tags = ["manual"] + tags,
testonly = testonly,
**kwargs
)
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
native.filegroup(
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
name = interface_output_name,
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
srcs = select({
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
"@bazel_tools//src/conditions:windows": [":" + dll_name],
"@bazel_tools//src/conditions:darwin": [":" + dylib_name],
"//conditions:default": [":" + so_name],
}),
output_group = "interface_library",
)
cc_import(
name = import_name,
interface_library = ":" + interface_output_name,
shared_library = select({
"@bazel_tools//src/conditions:windows": ":" + dll_name,
"@bazel_tools//src/conditions:darwin": ":" + dylib_name,
"//conditions:default": ":" + so_name,
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
}),
[Bazel] Get `//clang` building on Windows with clang-cl. This required substantially more invasive changes. We need to handle some of the LLVM `config.h` changes differently from the old pattern. These aren't always safe on the commandline, and the Windows ones specifically break Clang. Instead, use conditional defines in the header itself. This more closely matches how CMake builds see the definitions. I think this is also just cleaner and we should maybe move more of the macros out of Bazel. The config defines for Windows that I've kept in Bazel are the ones that LLVM's CMake does at the commandline as well. I've also added numerous ones that CMake uses and we didn't replicate in Bazel. I also needed a different approach to get `libclang` working well. This, IMO, improves things on all platforms. Now we build the plugin and actually wrap it back up with `cc_import`. We have to use a collection of manually tagged `cc_binary` rules to get the naming to work out the right way, but this isn't too different from the prior approach. By directly having a `cc_binary` rule for each platform spelling of `libclang`, we can actually extract the interface library from it and correctly depend on it with `cc_import`. I think the result now is much closer to the intent and to the CMake build for libclang. Sadly, some tests also needed disabling. This is actually narrower than what CMake does. The issue isn't indicative of anything serious -- the test just assumes Unix-style paths. I also have cleaned up the Windows flags in `.bazelrc` to much more closely match what CMake does. Differential Revision: https://reviews.llvm.org/D112399
2021-11-02 10:52:38 +08:00
alwayslink = alwayslink,
features = features,
tags = tags,
testonly = testonly,
)
cc_library(
name = name,
hdrs = hdrs,
include_prefix = include_prefix,
strip_include_prefix = strip_include_prefix,
deps = [":" + import_name],
alwayslink = alwayslink,
features = features,
tags = tags,
testonly = testonly,
Introduce a Bazel build configuration This patch introduces configuration for a Bazel BUILD in a side directory in the monorepo. This is following the approval of https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md As detailed in the README, the Bazel BUILD is not supported by the community in general, and is maintained only by interested parties. It follows the requirements of the LLVM peripheral tier: https://llvm.org/docs/SupportPolicy.html#peripheral-tier. This is largely copied from https://github.com/google/llvm-bazel, with a few filepath tweaks and the addition of the README. Reviewed By: echristo, keith, dblaikie, kuhar Differential Revision: https://reviews.llvm.org/D90352
2021-05-19 06:42:25 +08:00
)