`apple_test_all` won't run when pre-compiled libraries are included about bucksample HOT 11 CLOSED

Dynamic, currently adding Buck onto a project that we've split out to a number of modules prebuilt with Carthage. Should be able to take a look at this in the next day or two.

from bucksample.

I think this could be solved by no longer using libraries and instead declare your pre-built libraries directly as deps. I’m not positive though. Can confirm next week, but I think we moved from libraries recently due to a conversation in the Buck Slack.

Either way, we should have an example of a pre-built library in this repo.

from bucksample.

Ah, I think I misread the OP here. @dharr419-ford looks like you're saying that you are already declaring your precompiled libraries as deps, but they aren't being embedded transitively into your CI test target. Is your precompiled a library a static library or a dynamic library? I haven't seen this behavior before, so I'm trying to get a better sense of the issue.

from bucksample.

In #46, it didn't seem like I needed to do anything special in apple_test_all to support the SwiftWithPrecompiledDependency library. I'm curious how your configuration differs!

from bucksample.

So here's a simple way to reproduce the usual Library not loaded crash:

Cartfile:
github "krzyzanowskim/CryptoSwift"

Carthage/Buck:

prebuilt_apple_framework(
    name = "CryptoSwift",
    framework = "Build/iOS/CryptoSwift.framework",
    preferred_linkage = "shared",
    visibility = ["PUBLIC"],
)

Libraries/SwiftWithPrecompiledDependency/BUCK:

load("//Config:buck_rule_macros.bzl", "first_party_library", "mlmodel_resource")

first_party_library(
    name = "SwiftWithPrecompiledDependency",
    deps = [
        "//Pods:Fabric",
        "//Carthage:CryptoSwift",
    ],
)

Libraries/SwiftWithPrecompiledDependency/SwiftWithPrecompiledDependencyClass.swift:

import Fabric
import CryptoSwift

public class SwiftWithPrecompiledDependencyClass {

  public static var isFabricInDebugMode: Bool {
    return Fabric.sharedSDK().debug
  }

  public func printCryptoThings() {
    let data = Data(bytes: [0x01, 0x02, 0x03])
    print("Crypto: \(data)")
  }
  
}

Run carthage update and then buck test Libraries/SwiftWithPrecompiledDependencyClass and you'll get what I usually expect in Library not loaded: @rpath/CryptoSwift.framework/CryptoSwift.

I'm guessing there's some way to update the LD_RUNPATH_SEARCH_PATHS for this but I'm confused as to why it's needed for this but works fine the precompiled Pod

from bucksample.

Oh no. That there are differences between precompiled Carthage frameworks and precompiled Pods frameworks is absurdly frustrating. Let me play with the diff you just sent. Thank you for the explanation!

from bucksample.

This is a rough one. You're right that libraries compiled via Carthage in the deps list aren't transitively included in the test targets when the test is executed from Buck's command line interface.

After more investigation, it seems like building with Carthage creates a framework that isn't automatically included in test targets (though admittedly that sentence sounds crazy at face value). I don't yet understand why the pre-built Fabric library works, but a Carthage-build framework doesn't. Note I can use Carthage to bring in a pre-built Fabric framework (Carthage doesn't compile the framework, but rather downloads a pre-built version) and it works just fine.

from bucksample.

Huh, our experience is that anything pre-compiled in any way we've, within Xcode, had to embed the framework in the test targets or set the Runpath Search Paths to also include $(FRAMEWORKS_SEARCH_DIR), which we usually do because it reduces the size of the xctest bundles quite a bit (our apps are currently built out of a number of modules we precompile with Carthage). This holds for whether it's a Carthage built framework or something precompiled shipped to us by another team or pulled within Carthage.

But if I'm reading you right, the precompiled Fabric framework works fine?

from bucksample.

@thedavidharris: #46 seems to be working with a precompiled library, without a separate embed step. But I'm unable to get another precompiled library working without a separate embed step. I don't fully understand how #46 works, but I won't merge it + consider this task done until I do / add some reproduction steps.

from bucksample.

@dfed Fabric uses static libraries inside a .framework folder structure. Perhaps that is part of it?

from bucksample.

Aha! That would explain why I can only get Fabric to work without additional changes. With that information, I'm going to close #46, and give it another shot with a Carthage lib. This will certainly require more changes 😬

from bucksample.