Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Private and project level Objective-C headers no longer available in apple_test target

See original GitHub issue

While trying out the latest master branch (94647d7) I’ve noticed that behavior of apple_test rule has changed.

While previously I was able to build tests that use project-level headers, this is no longer possible with laster buck version.

E.g. if I have a project-level header in my framework target:

I can usually use it directly in my test cases. This works with Xcode and worked with older versions of buck as well. apple_test seemed to be able to find all headers from it’s “parent” apple_library target.

Latest version of buck breaks this behavior.

Is it intentional?

Using private or protected headers in tests is similar to Swift’s @testable import and seems to be an established pattern in iOS world.

Tools like CocoaPods offer options like inherit! :search_paths for test target to be able to find host target’s headers.

I believe previous buck behavior was more forgiving in that regards and more inline with what other tools do.

If the change was intentional, is there an option or workaround to make apple_test behave same as before?

Issue Analytics

State:
Created 5 years ago
Comments:16 (5 by maintainers)

Top GitHub Comments

2reactions

manojkarkicommented, Apr 18, 2019

Modular and bridging-headers are be two mutually exclusive concepts in swift. Either you have a modular library and import objective c into your swift using the -import-underlying-module flag (buck will automatically create a modulemap for the headers that are under exported_headers, or you specify a bridging header it will add that to the swiftc command.

It sounds like this is intended, but we should probably make the error messaging more clear by just throwing an error if you specify both a bridging header and modular=True.

What do you mean by

Modular and bridging-headers are be two mutually exclusive concepts in swift.

Is it BUCK only limitation because I think it is possible to have semantic import (modular lib) on a mixed Swift + Objective C lib? Can you please elaborate.

1reaction

robbertvanginkelcommented, Jun 19, 2018

Modular and bridging-headers are be two mutually exclusive concepts in swift. Either you have a modular library and import objective c into your swift using the -import-underlying-module flag (buck will automatically create a modulemap for the headers that are under exported_headers, or you specify a bridging header it will add that to the swiftc command.

It sounds like this is intended, but we should probably make the error messaging more clear by just throwing an error if you specify both a bridging header and modular=True.

Top Results From Across the Web

Need help to resolve error "using bridging headers with ...

1) Created Bridging header file and added into project target. 2)Added import statement to header file "#import <sqlite3.h>". 3) This header is marked...

How can I unit test project level apis of a target in objective c?

The problem that I am facing is that I am not able to import project/private headers. I am using XCode 10 and Objective-C...

Swift-Objective C interoperability and best practices - Infinum

In Build Settings, under Objective-C Bridging Header put the path to the one bridging header that remained for every target.

Objective-C and Swift Together | Swiftjective-C

This beautiful arrangement is due to swift's ability to be accessible to other swift files contained within the same module. For this reason, ......

apple_library() - Buck

An apple_library() rule represents a set of Objective-C/C++/Swift source files ... See the sections for the headers and exported_headers attributes for more ......