Summary
With current Tuist and Xcode, Swift macro executables are emitted as framework search paths. Xcode passes them to the linker as -F arguments, but the macro products are executable files rather than directories. This produces one warning per macro while the build otherwise succeeds.
Environment
- macOS 26.5.2
- Xcode 26.6 (17F113)
- Tuist 4.202.1
Reproduction
- Create a macOS Tuist project that declares these public Swift packages in
Tuist/Package.swift:
https://github.com/pointfreeco/swift-perception, version 2.0.10
https://github.com/pointfreeco/swift-structured-queries, version 0.31.1
https://github.com/pointfreeco/sqlite-data, version 1.6.1
- Add a framework target depending on the
SQLiteData external product (the dependency graph includes the macro targets).
- Run
tuist generate.
- Build the Debug configuration in Xcode.
Actual result
The generated target contains the following FRAMEWORK_SEARCH_PATHS entries:
$(CONFIGURATION_BUILD_DIR)$(TARGET_BUILD_SUBPATH)/PerceptionMacros
$(CONFIGURATION_BUILD_DIR)$(TARGET_BUILD_SUBPATH)/StructuredQueriesMacros
$(CONFIGURATION_BUILD_DIR)$(TARGET_BUILD_SUBPATH)/StructuredQueriesSQLiteMacros
The corresponding products are Mach-O executables directly inside $(CONFIGURATION_BUILD_DIR), not directories. During link, Xcode emits:
ld: warning: search path ".../Build/Products/Debug/<MacroName>" is not a directory
Expected result
Macro executables should be loaded through the generated Swift compiler flags, but they should not be added to FRAMEWORK_SEARCH_PATHS or emitted as linker -F paths.
Attempted workaround
I explicitly configured PerceptionMacros, StructuredQueriesMacros, and StructuredQueriesSQLiteMacros as .macro in PackageSettings.productTypes, then regenerated. The generated FRAMEWORK_SEARCH_PATHS entries were unchanged.
Privacy note
This report intentionally uses only public dependency versions and generic build-path placeholders. It omits local absolute paths, project identity, bundle identifiers, signing data, and repository URLs.