fix: OSX toolchain and MoltenVK build fixes

[Subaskar-S]

Summary

• Fix GSL submodule URL from relative path to full GitHub URL (breaks fresh clones)
• Propagate CMAKE_MAKE_PROGRAM, CMAKE_OSX_SYSROOT, CMAKE_OSX_SYSROOT_INT, CMAKE_OSX_ARCHITECTURES to subprojects in CommonCompilerOptions
• Fix malformed xcodebuild command in MoltenVK build.sh (missing closing quote, ONLY_ACTIVE_ARCH tangled into wrong argument)
• Make CMAKE_DEVELOPER_ROOT resolution non-fatal for Command Line Tools-only setups (no full Xcode)

Built and verified on macOS with Command Line Tools. MoltenVK xcodebuild command now runs correctly for both Debug and Release variants.

[itsafuu]

Get update from develop on ipfs-lite-cpp/libp2p develop, and make sure this compiles on SuperGenius/develop -> GeniusSDK/develop

[itsafuu]

Also relative path to GSL would resolve to GeniusVentures/GSL fork, I don't know what you mean by breaks fresh clones, I have never had an issue cloning.

[Subaskar-S]

You're right about the GSL URL GSL.git resolves correctly to GeniusVentures/GSL. I've removed that change from the PR. The remaining three changes are real issues I hit:

• MoltenVK build.sh — the original command has an unclosed quote with ONLY_ACTIVE_ARCH=NO tangled inside -archivePath "${INSTALL_DIR}. xcodebuild treats everything after the unclosed quote as one argument and fails.
• CommonCompilerOptions.CMake — CMAKE_MAKE_PROGRAM and CMAKE_OSX_* weren't propagating to subprojects.
• apple.toolchain.cmake — CMAKE_DEVELOPER_ROOT was fatal when CMAKE_OSX_SYSROOT_INT is empty.

I'll pull the latest from develop on ipfs-lite-cpp/libp2p and verify it compiles through SuperGenius/develop → GeniusSDK/develop.

[Subaskar-S]

Hi @itsafuu ,Thanks for the feedback. I did a full verification of the build across the macOS toolchain and found that the remaining changes address real build-breaking issues rather than optional improvements.

Summary of required fixes:

1. SGProcessingManager (SuperGenius/develop)
   get_parameters() returns a boost::optional by value. Taking &processing_.get_parameters().value() results in taking the address of a temporary rvalue, which is undefined behavior and a hard compiler error on Clang (15+).
   → Fixed by storing the optional in a local variable before accessing .value().

2. CommonBuildParameters.cmake (protoc path)
   The build was pointing to protobuf/bin/protoc (target binary) instead of protobuf_host/bin/protoc (host binary), causing proto generation to fail.
   → Updated to use the correct host protoc.

3. CommonBuildParameters.cmake (target alias)
   SuperGenius exports sgns::sgns_genius_account, while GeniusSDK links against sgns::sgns_account.
   → Added a compatibility alias to resolve the mismatch and allow CMake generation to succeed.

4. GeniusSDK.cpp (string handling)
   strncpy was used with std::string fields, which fails to compile on the current Xcode SDK due to stricter type checks.
   → Replaced with direct std::string assignment.

All of the above were reproducible build failures on macOS (Xcode 26.x / Clang 15+). After applying these fixes, I was able to complete a clean build of SuperGenius → GeniusSDK successfully.

If you have time, could you please take a look and let me know if this approach is fine?

[itsafuu]

1. Yes, this is almost certainly correct, AI really likes to do this with the boost optional, I've had to fix several other similar instances. Make a PR there into proc schema.
2. I don't know much about this at the moment, are we talking about SuperGenius? Set up a PR there.
3. Why alias? Just have SDK link to sgns::sgns_genius_account. It was recently changed from sgns::sgns_account on develop so it needs updated in the SDK.
4. I find this surprising, I'm pretty sure my Apple clang version 21.0.0 (clang-2100.0.123.102) handles this fine.

[Subaskar-S]

Thanks, that makes sense. For the target issue, I’ll update the SDK to link directly against sgns::sgns_genius_account instead of adding the alias.

I’ll also recheck the strncpy case carefully against the current branch/types before keeping that change, since it may be toolchain/version-specific on my setup.

I’ll split the fixes into the appropriate repos/PRs and update accordingly.