Problems integrating into a "Run Script" Build Phase, getting "database is locked" error during build

[tatewake]

Hi there,

I'm trying to integrate periphery into an existing app build, since the warnings generated are very helpful.

I figured I'd try to make periphery run as a "Run Script" either after "Compile Sources" or at the very last step of my build (similar to how I've integrated SwiftLint and SwiftFormat):

But if I do, I get this error:

accessing build database "/Users/terence/Library/Caches/com.github.peripheryapp/DerivedData-X-X_Dev/Build/Intermediates.noindex/XCBuildData/build.db": database is locked Possibly there are two concurrent builds running in the same filesystem location.

I notice that if I use the option --skip-build, I don't get this error, but the warnings I see generated by periphery are out of date to what the actual code looks like. (I believe these warnings are cached from when I ran periphery via the command line.)

Do you have any suggestions for how I might accomplish this? (Without having to say run the generated app or tests.)

I realize this use case is not necessarily covered in your README, but it would be useful to have this run every time I select "build" to get a list of what's unused in my codebase.

[ileitch]

Unfortunately running Periphery from a build target phase isn't really supported, and as you've encountered likely doesn't work.

The first issue is that it doesn't make conceptual sense to run Periphery from a single target, because by its nature Periphery typically analyses more than just one build target (the exception being for simple apps). You'd need to ensure that the build target containing your build phase script also builds all other targets that Periphery needs to analyze as dependencies. While that's certainly doable in some cases, in others it's perhaps not because Periphery may need to also analyze test targets for example in order to produce accurate results. This is why the README only guides you through creating a new aggregate target and schema.

The other issue (or issues) is that running Periphery from within Xcode's environment has in the past caused bugs because certain environment variables would affect the underlying build performed by Periphery. That's why Periphery now runs all sub processes in a completely isolated environment. A consequence of that is that Periphery no longer has access to the env var that identifies Xcode's DerivedData location, and subsequently the location of the index store db. This why using the --skip-build option doesn't produce the results you're expecting, because Periphery isn't using the index store db generated by Xcode, it's using a different db in a location generated when you last ran Periphery from the command line. Furthermore, even if Periphery could use --skip-build and access the index store db generated by Xcode, it's possible the index store doesn't contain data for all targets as explained above.

I'm not sure why Xcode is failing with the error you're seeing. You can see from the error that Periphery is in fact using its own DerivedData location. 🤷‍♂️

SwiftLint and SwiftFormat in some regards are simpler to operate than Periphery because they don't need to analyze your project as a whole, they can instead analyze source files on an individual basis.

So, given the conceptual and technical challenges of using Periphery like this, it's unlikely to be supported in the near future. Having said that, it may still be possible to get this working in some fashion. You can instruct Periphery to use an index store db at a given location, so you could try point it directly at the one generated by Xcode. For example:

periphery scan ... --skip-build --index-store-path ${BUILD_ROOT}/../../Index/DataStore

But keep in mind what I said above about the set of targets you've asked Periphery to analyze, and the actual targets that are built by your build target.

[tatewake]

My apologies for not following up, I got a little busy. I just wanted to thank you for your help. I think we'll just end up using your library as originally intended as a separate aggregate target. Thank you for your work.