LDC: Don't keep around temporary object files for static libs #2690
Conversation
|
✅ PR OK, no changes in deprecations or warnings Total deprecations: 0 Total warnings: 0 Build statistics: statistics (-before, +after)
executable size=5259464 bin/dub
rough build time=62sFull build output |
kinke
force-pushed
the
ldc_temp_objects
branch
from
7eae6f1 to
050ca7f
Compare
source/dub/compilers/ldc.d
Outdated
| settings.addDFlags("-lib"); | ||
| // -oq: name object files uniquely (so the files don't collide) | ||
| // -cleanup-obj: remove object files after archiving to static lib, and put them in a unique temp directory | ||
| settings.addDFlags("-lib", "-oq", "-cleanup-obj"); |
There was a problem hiding this comment.
are the new flags not required for the dynamicLibrary case below?
There was a problem hiding this comment.
Nope; the object files for executables and shared libs are persisted/kept around, by dub and the compilers alike. Static libs with DMD are a special case, as it writes the static lib directly itself, without creating separate object files and then archiving them, like LDC and GDC. ldmd2 -lib also injects these 2 extra flags for the ldc2 cmdline to mimic the DMD behavior.
|
|
||
| exit 0 | ||
| numObjectFiles=$(find "$DUB_CACHE_PATH" -type f -iname '*.o*' | wc -l) | ||
| [ "$numObjectFiles" -eq 0 ] || die $LINENO "Found left-over object files in $DUB_CACHE_PATH" |
There was a problem hiding this comment.
this change seems to revert what has previously been published in the changelogs: kinke@176ea9c
Enables co-existence and parallel compilation of the same project with different settings (e.g. cross compilation) by moving
.dub/objto$DUB_TARGET_PATH/obj.
Although that changelog entry seems faulty right now, since it didn't actually write to the target path (e.g. "targetPath": "bin") but to the build cache path.
So I think this change is fine.
There was a problem hiding this comment.
With LDC v1.25+, this PR solves the concurrency problem more robustly - each compiler invocation uses a unique temp dir for its object files, no need to specify unique-ish paths explicitly.
|
The flag was introduced in LDC v1.1 in 2016: ldc-developers/ldc@141310c It's just that since v1.25 it additionally implies a concurrent-safe unique temp dir instead of the cwd (if you don't specify a |
kinke
force-pushed
the
ldc_temp_objects
branch
2 times, most recently
from
23f95fa to
0fb13ce
Compare
This was a workaround for older LDC versions. Since LDC v1.25, `-cleanup-obj` implies that the temporary object files are placed into a unique temp directory (per compiler invocation), so that object file collisions across parallel dub invocations cannot happen anymore.
|
@WebFreak001: Okay, I've re-added support for all LDC versions. |
Co-authored-by: Mathias LANG <geod24@gmail.com>
|
@kinke : This broke While building a project that depends on https://github.com/deviator/barcode (although I think that will trigger for any dependency, this is just the first one). Broken: |
|
I guess it needs |
|
Oh, looks like a potential misconfig for |
|
=> #2994 |
This was a workaround for older LDC versions. Since LDC v1.25,
-cleanup-objimplies that the temporary object files are placed into a unique temp directory (per compiler invocation), so that object file collisions across parallel dub invocations cannot happen anymore.