The former has been deprecated and will break by
--incompatible_use_platforms_repo_for_constraints, as announced in
https://github.com/bazelbuild/bazel/issues/8622.
Fixes #354.
Co-authored-by: UebelAndre <andre.brisco@gmail.com>
This change allows rules_foreign_cc to work on architectures other
than x86_64.
Bug: bazelbuild/bazel#11628
Test: manual. no longer fails with "ln: illegal option -- t" on darwin_arm64
There's now a top level bzl_library @rules_foreign_cc//:bzl_srcs that contain the .bzl sources for the build rules defined in this repo.
Stardoc support was also added to ensure the bzl_library structure is correct and usable outside of the repo. In addition to this, new documentation can be generated by running bazel run //docs:generate_docs from the root of rules_foreign_cc/examples to output @rules_foreign_cc_tests//docs:README.md.
Fix shell function symlink_contents_to_dir, add test
- test for the case when we symlink the contents of two directories with the same inner directories (include)
- the test data of the test for shell script helper also changes, as it uses the real shell toolchain implementation text
- Fixes the issue from #330
* Fix permission problem with replacing absolute path with sed, #306
- we can not modify files under Bazel's output directory
- so we can not modify pkg_config files, written there, for instance
- solution: only replace absolute paths in the files being created by the current target,
using the environment variable as the replacement value ($EXT_BUILD_DEPS)
* Wrap environment variable in ${} in replace string
* Fix replace_in_files function in windows_commands.bzl
Filter files by types, where the absolute paths need to be replaced.
* Add one more hello world example
* Include test into windows list, remove from Mac OS list
Fix #232 - enable usage of Bazel-built libraries as dependencies of cmake_external and configure_make.
- fix logic of reading library data described by C/C++ Bazel interface (as CcInfo.linking_context appeared)
- symlink transitive include directories under $EXT_BUILD_DEPS
- gather all possible transitive include directories to pass to CMake, pass transitive include directories to CMAKE_PREFIX_PATH so that the transitive include directories were scanned by CMake
- fix logic of passing transitive libraries into CPPFLAGS (configure_make)
- add test with the chain: Bazel lib -> CMake lib -> Bazel cc_test
- add synthetic configure-make test with the chain: Bazel lib -> configure_make lib -> Bazel cc_test
- also notice, that passed include directories from Bazel C/C++ Sandwich interface are not always existing; for now, make symlinking code resistant to that
see https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Preset-Output-Variables.html
* Improve outputs handling: wrapper script in shell-abstract manner
- extract wrapper script creation into a separate function,
- simplify the script and log names, also output the wrapper script text,
- introduce more shell primitives
related to #204
* Correct review comments
* Register shell toolchain implementations in the correct order
so that the default implementation is the last
* Refactor shell toolchain to allow users register custom shell toolchains.
- define your own shell toolchain file(s) by copying @rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains/impl:linux_commands.bzl,
and modifying the methods.
- create a mapping: a list of ToolchainMapping with the mappings between created file(s) and execution or/and target platform constraints.
- in the BUILD file of some package, call "register_mappings" macro from "@rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains:defs.bzl", passing the mappings and toolchain_type_ = "@rules_foreign_cc//tools/build_defs/shell_toolchain/toolchains:shell_commands"
- in the WORKSPACE file of your main repository, when you initialize rules_foreign_cc, pass the mappings and the package, in which BUILD file you called "register_mappings" macro
* Correct typo
* Extract shell fragments into a toolchain
Construct script in framework.bzl using special notation for calling
shell fragments, defining and referencing environment variables;
have the script converted from this special notation into a real script
(see README.md notes.)
The special notation is used to keep script construction in code still readable.
Tools scripts (cmake, ninja) were also converted.
* Fix reference to environment variables in examples
.. and reference it correctly $$var_name$$ so it is replaced further
* Review comments: documentation, explicitly mark functions from toolchain
- mark functions from shell toolchain as ##funname##, so that they
can not be mixed with usual shell functions
* Fix operating system name for windows in toolchain file
* Additional env vars for windows
* Correct cmake tool build
* Do not build ninja on Windows
* When run on Windows under msys, find utility from Window could "leak"...
into the script. Use heuristics to use /usr/bin/find if it exists.
Also, use pwd -W to get Windows-styled paths (for cmake)
