You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When switching from multithreadingSupport=false -> true while having incremental compilation enabled, I've seen that the toolchain would not start a new, clean build, but would rather use the already compiled .ll files. Normally it would be expected, when using the same config, as it allows to skip redundant work. However, when build changes to produced outputs shall also change, and should not be reused!. Especially in case of multithreading which does change a way in which we do lower Op.Module operations. This leads to compilation errors until doing a manual cleanup.
Fix: Make sure that when NativConfig changes the backend does not use cached .ll files
The text was updated successfully, but these errors were encountered:
…Config changes
Fix: scala-native#3567
Previously, the scala-native would not start a new, clean build when switching from `multithreadingSupport=false -> true`
while having incremental compilation enabled.
This was because it would reuse the already compiled cached native-lib nir files.
However, when `nativeConfig` (especially `multithreadingSupport`) changes, which affects the native-lib code
scala-native shouldn't reuse the cached native-lib.
This led to compilation errors until doing a manual cleanup.
This commit fixes this issue by removing stale native-config-* directories when the `nativeConfig` changes.
To do that, we added a hashCode of nativeConfig to the native-lib's
directories.
```
❯ ls -l sandbox/.3/target/scala-3.3.1/native | grep native-code
... native-code-clib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-1/
... native-code-javalib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-2/
... native-code-nativelib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-0/
... native-code-posixlib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-3/
... native-code-windowslib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-4/
```
…Config changes
Fix: scala-native#3567
Previously, the scala-native would not start a new, clean build when switching from `multithreadingSupport=false -> true`
while having incremental compilation enabled.
This was because it would reuse the already compiled cached native-lib nir files.
However, when `nativeConfig` (especially `multithreadingSupport`) changes, which affects the native-lib code
scala-native shouldn't reuse the cached native-lib.
This led to compilation errors until doing a manual cleanup.
This commit fixes this issue by removing stale native-config-* directories when the `nativeConfig` changes.
To do that, we added a hashCode of nativeConfig to the native-lib's
directories.
```
❯ ls -l sandbox/.3/target/scala-3.3.1/native | grep native-code
... native-code-clib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-1/
... native-code-javalib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-2/
... native-code-nativelib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-0/
... native-code-posixlib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-3/
... native-code-windowslib_native0.5.0-SNAPSHOT_3-0.5.0-SNAPSHOT--1554901494-4/
```
When switching from
multithreadingSupport=false
->true
while having incremental compilation enabled, I've seen that the toolchain would not start a new, clean build, but would rather use the already compiled.ll
files. Normally it would be expected, when using the same config, as it allows to skip redundant work. However, when build changes to produced outputs shall also change, and should not be reused!. Especially in case of multithreading which does change a way in which we do lowerOp.Module
operations. This leads to compilation errors until doing a manual cleanup.Fix: Make sure that when NativConfig changes the backend does not use cached
.ll
filesThe text was updated successfully, but these errors were encountered: