Multiple files with the same name exists
Detailscool opened this issue · 1 comments
/Users/aaa/bbb/IntegrationTests/DevelopmentPods/FFmpeg/BUILD.bazel:36:16: in apple_framework_packaging rule //IntegrationTests/DevelopmentPods/FFmpeg:FFmpeg_ios:
Traceback (most recent call last):
File "/Users/aaa/bbb/bazel-output-base/rules_xcodeproj.noindex/build_output_base/external/build_bazel_rules_ios/rules/framework.bzl", line 995, column 43, in _apple_framework_packaging_impl
framework_files = _get_framework_files(ctx, deps)
File "/Users/aaa/bbb/bazel-output-base/rules_xcodeproj.noindex/build_output_base/external/build_bazel_rules_ios/rules/framework.bzl", line 441, column 45, in _get_framework_files
headers_out = _framework_packaging_multi(ctx, "header", headers_in, headers_out, framework_manifest)
File "/Users/aaa/bbb/bazel-output-base/rules_xcodeproj.noindex/build_output_base/external/build_bazel_rules_ios/rules/framework.bzl", line 240, column 45, in _framework_packaging_multi
_framework_packaging_symlink_headers(ctx, inputs, outputs)
File "/Users/aaa/bbb/bazel-output-base/rules_xcodeproj.noindex/build_output_base/external/build_bazel_rules_ios/rules/framework.bzl", line 200, column 17, in _framework_packaging_symlink_headers
fail("""
Error in fail:
[Error] Multiple files with the same name exists.
See below for the list of paths found for each basename:
{"log.h": ("IntegrationTests/DevelopmentPods/FFmpeg/FFmpeg/FFmpeg/include/librtmp/log.h", "IntegrationTests/DevelopmentPods/FFmpeg/FFmpeg/FFmpeg/include/libavutil/log.h"), "version.h": ("IntegrationTests/DevelopmentPods/FFmpeg/FFmpeg/FFmpeg/include/libavformat/version.h", "IntegrationTests/DevelopmentPods/FFmpeg/FFmpeg/FFmpeg/include/libswresample/version.h")}
how to handle same files like FFmpeg, modify .h's name makes no sense
Yes, stumbled upon the same problem. Looking at the source code of rules/framework.bzl
, it seems the framework rule cannot handle hierarchically organized header files. It assumes, that all header files of a framework are a flat structure. This is nothing that Apple xcodebuild
requires.
Actually this is a real bug, as header hierarchies must stay intact.