Open swwol opened 1 year ago
A bit more info on this: sourcery seems to be generating some .swift files and writing them to the system temp directory when it runs.. I think the build is seeing these as input files which is causing issues. Are these files required for sorcery to run and if not is there a way to prevent them from being generated?
Specifically these files are appearing in temp directory:
AccessLevel.swift BytesRange.swift Diffable.generated.swift GenericRequirement.swift Protocol.swift Typealias.swift Actor.swift Class.swift Diffable.swift Import.swift ProtocolComposition.swift Typed.generated.swift Annotations.swift Closure.swift Documentation.swift JSExport.generated.swift Struct.swift Typed.swift Array+Parallel.swift Coding.generated.swift Enum.swift Log.swift Subscript.swift Variable.swift Array.swift Composer.swift Equality.generated.swift Method.swift TemplateContext.swift AssociatedType.swift Definition.swift Extensions.swift Modifier.swift Tuple.swift Attribute.swift Description.generated.swift FileParserResult.swift ParserResultsComposed.swift Type.swift AutoHashable.generated.swift Dictionary.swift Generic.swift PhantomProtocols.swift TypeName.swift
do you have .swifttemplates?
I do - (it's the .swifttemplate used by swiftymocky) I delved into the source code a little and kinda understand what is going on now. Thinking of making a fork which allows an argument to set a custom build directory, which could be the plugins packageWorkDirectory. This should be different for every target so I think will resolve the issue I am having. Do you think that would be a good way forward?
a PR with optional build directory sounds good to me
Hi @swwol, we are trying to achieve the build the same plugin for our iOS app which is modularized extensively using SPM. could you share how you achieved this for your own needs?
Thank you, Victor
Only just come back to see this comment a year later! but in case its still useful, the key was to set the cache path to the plugin work directory - then every package uses a separate cache. Here is the command being run:
extension Command {
static func swiftymocky(context: SwiftyMockyContext, inputs: [Path]) throws -> Command {
.buildCommand(
displayName: "SwiftyMocky BuildTool Plugin",
executable: try context.tool(named: "sourcery").path,
arguments: [
"--config", context.modifiedConfigPath.string,
"--cacheBasePath", context.pluginWorkDirectory.appending("sourceryCache").string,
"--buildPath", context.pluginWorkDirectory.string,
],
environment: [:],
inputFiles: inputs,
outputFiles: [context.pluginWorkDirectory.appending("Mock.generated.swift")]
)
}
}
Thanks @swwol, will give that a go. I think this may relate to: https://github.com/krzysztofzablocki/Sourcery/issues/1322
@swwol are you able to use your sourcery buildCommand
with Mock.swifttemplate
template such as this one:
I'm trying to make a buildtool plugin which uses the sourcery binary to generate mocks. When using this plugin on a single package, it works fine. But if compiling a project where the plugin is used in more than one package I get this error:
accessing build database "/private/var/folders/bl/dpyystbj1szdr_rzp6p1fwq40000gn/T/SwiftTemplate/2.0.1/.build/arm64-apple-macosx/build.db": database is locked Possibly there are two concurrent builds running in the same filesystem location.
Any suggestions for a solution appreciated!