Closed grillo-delmal closed 1 month ago
github-actions[bot]
commented
10 months ago ✅ PR OK, no changes in deprecations or warnings
Total deprecations: 14
Total warnings: 0
Build statistics:
statistics (-before, +after)
executable size=5331080 bin/dub
rough build time=64s
WebFreak001
commented
9 months ago I don't think this will use the dependency from tmp-dir, right? It rather looks like it would just reuse the already present binary, if any, in that case and cause build failure due to file system issues to use old binaries, which is a no-go.
If the DUB packages are in a read-only filesystem, I think you need to rather specify --cache=local|system|user to the correct value. Ideally this should be possible to be settable using the dub settings.json, but isn't yet
grillo-delmal
commented
9 months ago I think you need to rather specify
--cache=local|system|userto the correct value.
Even if you set the --cache parameter, running dub build will still fail if the dependency library sources are located in a read-only folder. This is because the process tries to move the resulting binaries from the build cache into the source folder during the build process (and thus why the exception is triggered). I have tested this on the use cases described in this repository: https://github.com/grillo-delmal/dub-system-wide-lib-tests .
What I'm trying to patch here is that, when the process correctly builds a dependency and fails to move the resulting binaries to the source code path, stop the process from crashing and continue the build process, skipping the part where the resulting dependency binaries are moved to the source directory.
In the piece of code I modified, the settings.tempBuild variable is only true if you are using dub run instead of dub build. The only thing that gets skipped by applying the patch is a call to updateCacheDatabase, which I assume its there to update the new built dependency path after it was moved correctly.
In this context, the only thing that I'm assuming is that if you don't call the updateCacheDatabase method, the build process will search for the built binary in the library build cache. I assume this considering that dub run works fine even if it doesn't need to run this code block. Please correct me if I'm wrong :)
Do you mean that, in the case where you have an older binary available in the source directory, the cache database will point to that file even if a new one was just built and is available in the build cache? Wouldn't this still be a problem if you try to run dub run without any changes?
edit: Trying to make sense x100. Sometimes even I can't understand what I write
grillo-delmal
commented
1 month ago I'll close this and approach it from another perspective
When you try to build an app with dub and one of their dependencies is located in a read-only directory, the whole process fails with the following message (when running with --vverbose):
This patch adds code to catch that exception and stop the dependency from being copied to the target directory, letting the build process to continue using the dependency results directly from the tmp-dir.
This might help to solve #1473