oneTBB as a Swift Package.

[furby-tm]

Hello,

I'd like to bring to your attention the importance of oneTBB as a significant dependency within the broader context of the Metaverse project. The term "Metaverse", in this context, refers to open-source software built upon the foundation of the ASWF landscape, with Pixar's Universal Scene Description at its core. It's worth noting that Pixar's Universal Scene Description also relies on TBB as a crucial dependency.

The Wabi Foundation (@wabiverse) is currently hosting a monorepo that contains all the dependencies for this underlying landscape, which can be found here. Our primary objective is to bring Pixar's USD to the Swift programming language. To achieve this, we aim to have all dependencies of USD provide their own Package.swift file at the root of their respective repository. This approach would allow us to avoid maintaining a monorepo while leveraging the capabilities of the Swift Package Manager, which can compile Objective-C/C++, C/C++, in addition to Swift.

For your convenience, I have prepared a potential Package.swift configuration for oneTBB, which you can find in this code snippet here.

I'm more than willing to submit a Package.swift as a Pull Request if the developers of oneTBB are open to supporting this initiative.

Thank you for your consideration.

[isaevil]

Hi @furby-tm. Thanks for you interest in contribution to oneTBB! We can accept your PR with support for Swift Package Manager, but the feature itself would be a community-supported though.

[furby-tm]

@isaevil I'm very happy to hear this, this is great news! I am out of town but will issue a PR to support SwiftPM as soon as I'm back at my office. Thank you very much!

[arunparkugan]

@isaevil is this issue is still relevant?

[isaevil]

@arunparkugan I believe @furby-tm was planning to open a PR for that. @furby-tm is this still relevant?

[furby-tm]

@isaevil It's still relevant! Sorry for keeping this issue hanging for so long, Swift needs to incorporate this fix for Linux before oneTBB can have it's own Package.swift manifest file.

Sorry for leaving this issue open for an eternity!

[wtholliday]

FWIW I'm also working on getting oneTBB into Swift Package Manager, but I'm taking the approach of a binary framework, built using this script: https://github.com/audulus/tbb-spm/blob/main/xcframework.sh

A pure Swift Package that doesn't use a binary is probably preferable though.

[furby-tm]

@wtholliday

FWIW I'm also working on getting oneTBB into Swift Package Manager, but I'm taking the approach of a binary framework, built using this script: https://github.com/audulus/tbb-spm/blob/main/xcframework.sh

A pure Swift Package that doesn't use a binary is probably preferable though.

Yeah, creating a binary .xcframework will only allow it to be utilized on Apple family devices.

I have oneTBB building in a SwiftPM package, compiling from source across Linux, Windows, macOS, visionOS, and iOS here, it's the OneTBB, TBBMalloc, and TBBMalloc, and MetaTBB Swift targets specifically.

The goal is to clean it up / not have to do any directory re-structuring for a PR to this repo.

[wtholliday]

@furby-tm I'm trying to add a Package.swift in the oneTBB directory. Setting it up like this:

.target(
            name: "OneTBB",
            path: ".",
            sources: ["src/tbb/arena.cpp"],
            publicHeadersPath: "include",
            cxxSettings: [
                .define("_XOPEN_SOURCE", to: "1"),
                .define("__TBB_BUILD"),
                .define("TBB_NO_LIB_LINKAGE")
            ]
        ),

The publicHeadersPath can't be outside the path, so that forces path to be ..

I get the error:

Multiple commands produce '.../Build/Products/Debug-iphoneos/tbb_OneTBB.bundle/en.lproj/MainMenu.nib'

So it seems SPM has inferred an executable of some sort. Seems harder to shoehorn this into SPM than build out a binary.

[furby-tm]

So it seems SPM has inferred an executable of some sort. Seems harder to shoehorn this into SPM than build out a binary.

Yes, it's certainly a bit complicated to get things to line up, SwiftPM offers very little flexibility in the configuration.

---

I get the error:

Multiple commands produce '.../Build/Products/Debug-iphoneos/tbb_OneTBB.bundle/en.lproj/MainMenu.nib'

I've however not a clue how it's picked up a bundle, or what that .nib is doing in there or any of that, the only way to create a .bundle is by specifying a resources path in your target's SwiftPM configuration (which resource bundles are actually a highly convenient and modular way to bundle up resources with your library or executable, cross-platform too), however you do not appear to be doing that, so that is quite odd, I must say I've seen a lot of weird stuff but this probably takes the cake 😆.

Are you attempting to utilize Xcode for this by chance? I believe that may be adding a whole lot of confusion here, you should have much better results using the Swift CLI in your terminal and just running the swift build command to build your Swift package, if you'd still like to use Xcode, there should be no problems with doing that - but I've found it's much easier to get the Swift Package successfully compiling with the Swift CLI first, before trying to build it from Xcode.

---

As an aside...

Note, if your intended target is iOS you can do so by installing @stackotter's SwiftBundler, however; utilize my fork of the project which supports properly building and bundling iOS and visionOS projects:

git clone https://github.com/wabiverse/wabi-swift-bundler
cd wabi-swift-bundler

swift build -c release
sudo cp .build/release/swift-bundler /usr/local/bin/

One limitation of the bundler however; is it only bundles apps, so to fulfill the needs of the bundler to build OneTBB for iOS, you'll have to create a dummy executable target in the Package.swift file:

// ...
.executableTarget(
  name: "OneTBBTestApp",
  dependencies: [
    .target(name: "OneTBB")
  ],
  swiftSettings: [
    .interoperabilityMode(.Cxx)
  ]
)

With dummy app code that looks like this:

// Sources/OneTBBTestApp/OneTBBTestApp.swift
import OneTBB
import SwiftUI

@main
struct OneTBBTestApp: App {
  var body: some Scene {
    WindowGroup {
      VStack {
        Text("Hello OneTBB!")
          .font(.system(size: 24, weight: .black))
          .padding()
      }
    }
  }
}

And create a file called Bundler.toml at the root of the repository:

format_version = 2

[apps.OneTBBTestApp]
identifier = 'com.intel.OneTBBTestApp'
product = 'OneTBBTestApp'
version = '1.0.0'
category = 'public.app-category.graphics-design'

[apps.OneTBBTestApp.plist]
commit = '$(COMMIT_HASH)'

Then run the following to test it on an iOS device:

# list available iOS and visionOS simulators.
swift bundler simulators

# boot a simulator from the list.
# note, currently the bundler is hardcoded to run on the first
# device it finds, for me that is the iOS 18 iPhone SE, you
# can find out which specific device its attempting to build
# for by running 'swift bundler bundle -p iOSSimulator' and
# checking the warning for "using first of multiple matching
# destinations".
swift bundler simulators boot [id-of-device]

# as long as the proper iOS simulator is running,
# this will then build and bundle your OneTBB test
# app and then proceed to run it on the simulator.
swift bundler run -p iOSSimulator OneTBBTestApp

[furby-tm]

@wtholliday ^ sorry forgot to ping you.

[wtholliday]

Thanks! Yeah it builds from the command line now. I had to rename src/tbb/main.cpp to src/tbb/tbbmain.cpp otherwise I get:

swift build
warning: 'onetbb': 'OneTBB' was identified as an executable target given the presence of a 'main.swift' file. Starting with tools version 5.4.0 executable targets should be declared as 'executableTarget()'
error: 'onetbb': library product 'tbb' should not contain executable targets (it has 'OneTBB')

(note there appears to be a bug in SPM, since it says main.swift not main.cpp)

Anyway, I've got a Package.swift that at least builds now, though I suspect some files are missing and I'll get link errors.

// swift-tools-version:5.10
import PackageDescription

let package = Package(
    name: "tbb",
    defaultLocalization: "en",
    platforms: [
        .macOS(.v11), .iOS(.v13)
    ],
    products: [
        .library(
            name: "tbb",
            targets: ["OneTBB", "TBBMalloc", "TBBMallocProxy"])
    ],
    targets: [
        .target(
            name: "TBBMallocProxy",
            dependencies: [
                .target(name: "OneTBB"),
            ],
            path: ".",
            exclude: ["src/tbbmalloc_proxy/tbbmalloc_proxy.rc", "src/tbbmalloc_proxy/CMakeLists.txt"],
            sources: ["src/tbbmalloc_proxy"],
            publicHeadersPath: "include",
            cxxSettings: [
                .define("_XOPEN_SOURCE", to: "1"),
                .define("TBBPROXY_NO_DLLMAIN")
            ]
        ),

        .target(
            name: "TBBMalloc",
            dependencies: [
                .target(name: "OneTBB"),
                .target(name: "TBBMallocProxy"),
            ],
            path: ".",
            exclude: ["src/tbbmalloc/tbbmalloc.rc", "src/tbbmalloc/def", "src/tbbmalloc/CMakeLists.txt"],
            sources: ["src/tbbmalloc"],
            publicHeadersPath: ".",
            cxxSettings: [
                .define("_XOPEN_SOURCE", to: "1"),
                .define("__TBBMALLOC_BUILD", to: "1"),
                .define("TBBMALLOC_NO_DLLMAIN")
            ]
        ),

        .target(
            name: "OneTBB",
            path: ".",
            exclude: ["src/tbb/tbb.rc", "src/tbb/CMakeLists.txt"],
            sources: ["src/tbb"],
            publicHeadersPath: "include",
            cxxSettings: [
                .define("_XOPEN_SOURCE", to: "1"),
                .define("__TBB_BUILD"),
                .define("TBB_NO_LIB_LINKAGE")
            ]
        ),
    ],
    cxxLanguageStandard: .cxx20
)

---

Re SwiftBundler: looks awesome but this is a dealbreaker:

Swift Bundler supports automatic compilation of Metal shaders, however all Metal shader files must be siblings within a single directory and they cannot import any header files from the project.

And also when I've put Metal code inside a Swift Package, it breaks support for the GPU debugger/profiler.

[wtholliday]

Ok when I try to use it in my main Xcode project, I get the same errors about xib files. So this seems like a dealbreaker. Back to the binary framework approach.

[furby-tm]

I had to rename src/tbb/main.cpp to src/tbb/tbbmain.cpp

You should also be able to add the path for the main.cpp file inside the exclude: [], array as well, instead of having to rename it.

Ok when I try to use it in my main Xcode project, I get the same errors about xib files. So this seems like a dealbreaker. Back to the binary framework approach.

This is very strange, I'm unsure how this .nib problem keeps propagating for you, I've yet to see this strange behavior myself, how are you adding the SwiftPM package to your Xcode Project?

Are you using Xcode's   File > Add Package Dependency   mechanism for adding your SwiftPM package to your project?

Also, which version of Xcode are you using?

---

Re SwiftBundler: looks awesome but this is a dealbreaker:

Swift Bundler supports automatic compilation of Metal shaders, however all Metal shader files must be siblings within a single directory and they cannot import any header files from the project.

And also when I've put Metal code inside a Swift Package, it breaks support for the GPU debugger/profiler.

Thanks for your feedback! I'll discuss this with @stackotter and see if we can make this work for you.

[furby-tm]

@wtholliday actually I had just taken another look at your code in your Package.swift again and had realized you had the following line of code in there:

defaultLocalization: "en",

This was causing issues, more info on what that field does is here.

Simply removing that line from the tbb swift package should no longer cause any of the errors you were seeing, and a library target package for a library such as OneTBB does not need any localization resources.

Sorry that I didn't catch that at first glimpse!

[wtholliday]

@furby-tm unfortunately removing that line doesn't work. I get:

manifest property 'defaultLocalization' not set; it is required in the presence of localized resources

which is why I added the line

[furby-tm]

@furby-tm unfortunately removing that line doesn't work. I get:

manifest property 'defaultLocalization' not set; it is required in the presence of localized resources

which is why I added the line

That is because you must remove your localized resources as well, reference.

[wtholliday]

@furby-tm ok I added "examples" to the excluded paths and that did it.