From 259966e07bd5b844efbc189e8e363818bdb54f9d Mon Sep 17 00:00:00 2001 From: Felix Deimel Date: Wed, 8 Jan 2025 09:39:20 +0100 Subject: [PATCH] Update readme to not include .net target framework in build paths --- README.md | 10 +++++----- README_MANUAL_BUILD.md | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 0325000..2a7e36b 100644 --- a/README.md +++ b/README.md @@ -90,14 +90,14 @@ public class Hello ``` - Compile the .NET class library: `dotnet publish`. -- Note the published dll's output path (should be something like this `/Path/To/BeyondDemo/bin/Release/net9.0/publish/BeyondDemo.dll`). +- Note the published dll's output path (should be something like this `/Path/To/BeyondDemo/bin/Release/publish/BeyondDemo.dll`). - Create a config file for Beyond.NET: `touch Config.json`. - Open `Config.json` in a text editor. - Replace its contents with this: ```json { - "AssemblyPath": "bin/Release/net9.0/publish/BeyondDemo.dll", + "AssemblyPath": "bin/Release/publish/BeyondDemo.dll", "Build": { "Target": "apple-universal" @@ -110,8 +110,8 @@ public class Hello - Run the generator: `beyondnetgen Config.json`. - On a Mac Studio M2 Ultra, this takes a little more than a minute while on an 8-Core Intel Xeon iMac Pro, it takes around 3 minutes. So it might be worth getting some coffee depending on your hardware. (TODO: Outdated info, as now with parallel building support the times are way better) - The individual code generation and builds steps are shown in the terminal. -- The last printed line should include the path where the build output has been written to (ie. `Build Output has been written to "/Path/To/BeyondDemo/bin/Release/net9.0/publish"`). -- Check the contents of the build output path: `ls bin/Release/net9.0/publish` +- The last printed line should include the path where the build output has been written to (ie. `Build Output has been written to "/Path/To/BeyondDemo/bin/Release/publish"`). +- Check the contents of the build output path: `ls bin/Release/publish` - It should include an XCFramework bundle called `BeyondDemoKit.xcframework`. - Congratulations, you now have a fully functional native version of your .NET library that can be consumed by macOS and iOS Xcode projects. @@ -131,7 +131,7 @@ Now that we have an XCFramework containing binaries for macOS and iOS, we can in - Select the `General` tab. - Under `Frameworks, Libraries and Embedded Content`, click the `+` button. - Select `Add Other... - Add Files...`. -- Navigate one level up in the file picker, then go to `bin/Release/net9.0/publish` (depending on your output path). +- Navigate one level up in the file picker, then go to `bin/Release/publish` (depending on your output path). - Select `BeyondDemoKit.xcframework`. - The XCFramework should now show up and it should already be configured to `Embed & Sign`. - Select `ContentView.swift` in the project navigator. diff --git a/README_MANUAL_BUILD.md b/README_MANUAL_BUILD.md index 8186fd0..8de3d7b 100644 --- a/README_MANUAL_BUILD.md +++ b/README_MANUAL_BUILD.md @@ -13,7 +13,7 @@ - Also, the install name of dylibs created by .NET's NativeAOT compiler needs to adjusted from `/usr/lib/MyLibNative.dylib` to `@rpath/MyLibNative.dylib`. - There's a sample publish script which does all of this in the repository called `publish_macos_universal`. You can use this as the basis for your build. Just make sure to adjust the `OUTPUT_PRODUCT_NAME` variable to match the assembly name of your .NET library (`MyLib`). - Run the publish script (ie. `./publish_macos_universal`). -- On macOS this will produce a universal `MyNativeLib.dylib` in the bin directory under `bin/Release/net9.0/osx-universal/publish`. +- On macOS this will produce a universal `MyNativeLib.dylib` in the bin directory under `bin/Release/osx-universal/publish`. ### Use generated bindings from Swift @@ -27,7 +27,7 @@ - Select "Add other... - Add files..." and select the native dylib (ie. `MyNativeLib.dylib`) - Try to build the project. If it fails, you might need to adjust either your header or library search paths in the project settings. - If Xcode fails to link the native dylib (the error looks something like this: `Library not found for -lMyNativeLib`) you need to adjust "Build Settings - Library Search Paths" in you project settings to point to the path where the library is located. - - For example, if the native library is located one level below your Xcode project in a folder called "MyLibNative/bin/Release/net9.0/osx-universal/publish" use this: `$(PROJECT_DIR)/../MyLibNative/bin/Release/net9.0/osx-universal/publish`) + - For example, if the native library is located one level below your Xcode project in a folder called "MyLibNative/bin/Release/osx-universal/publish" use this: `$(PROJECT_DIR)/../MyLibNative/bin/Release/osx-universal/publish`) - If Xcode complains about being unable to find the generated C header, adjust "Build Settings - Header Search Paths" to point to the path where the generated header is located. - For example, if your header is one level below your Xcode project in a folder called "Generated" use this: `$(PROJECT_DIR)/../Generated` - You're now ready to call any of the APIs that bindings were generated for.