Troubleshoot spdlog error

[izzy2lost]

Refactors CMake spdlog linking logic for Android builds and initializes missing submodules.

The project experienced spdlog errors due to conflicting linking strategies between the main CMakeLists.txt and the torch submodule's CMake configuration, particularly when spdlog was fetched via FetchContent for Android. This PR ensures spdlog targets are correctly identified and linked, and addresses an uninitialized torch git submodule that prevented successful compilation.

---

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[gemini-code-assist]

Summary of Changes

Hello @izzy2lost, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

I've refactored the CMake configuration to address persistent spdlog linking errors, particularly impacting Android builds. The updated logic now intelligently handles different ways spdlog might be provided in the build environment, ensuring correct linking. This change, along with addressing an uninitialized torch submodule, resolves compilation failures and stabilizes the build process.

Highlights

• Improved spdlog Linking Logic: The primary change involves updating the CMakeLists.txt file to improve how the spdlog library is linked, specifically to resolve issues encountered during Android builds. The new logic prioritizes finding existing spdlog targets, making the build process more robust.
• Submodule Initialization (Implicit): The pull request description mentions that an uninitialized torch git submodule was a contributing factor to compilation issues. While not directly visible in the provided diffs, resolving this would have been crucial for successful builds.
• Successful CMake Configuration Generation: The numerous added CMakeFiles and Makefile entries indicate that the CMake configuration process completed successfully after the changes, generating the necessary build system files. This confirms that the linking issues have been resolved at the configuration stage.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the CMake logic for linking spdlog to be more robust, especially for Android builds, and adds a number of generated CMake files. The change to libultraship/src/CMakeLists.txt is a good improvement. I have one suggestion to make the new logic even more robust and maintainable by separating the package finding from the linking logic.

[gemini-code-assist]

While this logic is a significant improvement over the previous platform-specific check, it can be made more robust and less repetitive. The current implementation repeats the linking logic and assumes that find_package(spdlog) will always provide the spdlog::spdlog target, which might not be true for all versions or configurations of spdlog.

A more robust and DRY (Don't Repeat Yourself) approach is to first ensure the package is found if no target exists, and then have a single block to decide which target to link. This handles various ways spdlog can be provided more cleanly and adds an explicit error if no target is found after trying to find the package.

if(NOT TARGET spdlog AND NOT TARGET spdlog::spdlog)
    find_package(spdlog REQUIRED)
endif()

if(TARGET spdlog::spdlog)
    target_link_libraries(libultraship PUBLIC spdlog::spdlog)
elseif(TARGET spdlog)
    target_link_libraries(libultraship PUBLIC spdlog)
else()
    message(FATAL_ERROR "Could not find spdlog target after find_package. Please check your spdlog installation.")
endif()