 | sbt | 2081 Members |
| Scala Build Tool | 5 Servers |
| sbt | 2081 Members |
| Scala Build Tool | 5 Servers |
| Sender | Message | Time |
|---|---|---|
| 22 May 2024 | ||
 ptrdom | And using coursier launch would work on shells but not play nice with IDEs. At least sbt BSP on IntelliJ IDEA would not work with that, unless I am unaware of some workaround. | 13:51:09 |
 velvetbaldmime | hmm what if you put --java-home <path> in .sbtopts? | 13:52:49 |
| ptrdom | That would probably work, but would not be cross-platform. | 13:54:05 |
| velvetbaldmime | right | 13:54:15 |
| velvetbaldmime | well you can start a discussion on sbt/sbt to embed some sort of target JVM bootstrap in sbt launcher ideally I'd put those things in project/build.properties like jvm = adoptium:11 | 13:55:13 |
| velvetbaldmime | * well you can start a discussion on sbt/sbt to embed some sort of target JVM bootstrap in sbt launcher ideally I'd put those things in project/build.properties like jvm = adoptium:11 and jvm.index= [some url] | 13:55:38 |
| ptrdom | Aha, that is a neat idea! I will start the discussion. | 13:56:00 |
| velvetbaldmime | I've been thinking about this for a long time 😄 Most recently due to the various new JDK versions and Scala versions being incompatible - would be good to ensure that one's build can basically launch sbt shell no matter what the host JDK is | 13:57:52 |
| ptrdom | That is probably the dream - similar to how the hosts sbt can download the project's sbt and boot it. | 13:59:06 |
| ptrdom | * That is probably the dream - similar to how the host's sbt can download the project's sbt and boot it. | 13:59:12 |
 gclaramunt joined the room. | 14:07:42 | |
 vasilmkd | Hello 👋🏻 As JetBrains, we forked https://github.com/JetBrains/sbt-kotlin-plugin from https://github.com/pfn/kotlin-plugin, as the original has been dormant for many years. We've only done surface level changes to the plugin in order to get it working with the latest versions of the Kotlin compiler. We use the plugin to build the Scala plugin for IntelliJ. It is necessary in order to interface with specific new APIs in the IntelliJ Platform. The sbt kotlin plugin is currently isolated to a few small sbt subprojects with a few Kotlin sources. sbt-kotlin-plugin is very simple and doesn't offer any sort of incremental compilation for the Kotlin sources. In fact, every time compile is issued, it recompiles all Kotlin sources without trying to track any changes or dependencies.It also compiles the Kotlin code before Zinc gets a chance to run. Therefore, the Kotlin code can only depend on Java symbols (the Kotlin compiler, similar to Scala, can produce stubs for Java classes) and already produced classfiles on the classpath (that's the only way Kotlin code can depend on Scala code in general). We've opened a tracking ticket for integrating the Kotlin compilation as part of the Zinc incremental compilation in sbt. https://youtrack.jetbrains.com/issue/SCL-22546/Develop-Kotlin-incremental-compilation-in-sbt-kotlin-plugin While I have some experience with using and calling Zinc, I've not yet had to expand its incremental compilation. Is there any way of hooking up the Kotlin sources and produced *.class files into the Zinc Analysis mechanism? I think it would get us 99% of the way there if we can have the following features (continuing in thread). | 21:55:04 |
| vasilmkd | * Hello 👋🏻 As JetBrains, we forked https://github.com/JetBrains/sbt-kotlin-plugin from https://github.com/pfn/kotlin-plugin, as the original has been dormant for many years. We've only done surface level changes to the plugin in order to get it working with the latest versions of the Kotlin compiler. We use the plugin to build the Scala plugin for IntelliJ. It is necessary in order to interface with specific new APIs in the IntelliJ Platform. The sbt kotlin plugin is currently isolated to a few small sbt subprojects with a few Kotlin sources. sbt-kotlin-plugin is very simple and doesn't offer any sort of incremental compilation for the Kotlin sources. In fact, every time compile is issued, it recompiles all Kotlin sources without trying to track any changes or dependencies.It also compiles the Kotlin code before Zinc gets a chance to run. Therefore, the Kotlin code can only depend on Java symbols (the Kotlin compiler, similar to Scala, can produce stubs for Java classes) and already produced classfiles on the classpath (that's the only way Kotlin code can depend on Scala code in general). We've opened a tracking ticket for integrating the Kotlin compilation as part of the Zinc incremental compilation in sbt. https://youtrack.jetbrains.com/issue/SCL-22546/Develop-Kotlin-incremental-compilation-in-sbt-kotlin-plugin While I have some experience with using and calling Zinc, I've not yet had to expand its incremental compilation. Is there any way of hooking up the Kotlin sources and produced *.class files into the Zinc Analysis mechanism? I think it would get us 99% of the way there if we can have the following features (continuing in the next message). | 21:55:26 |
| vasilmkd | 1. Track *.kt source files and their stamps, such that edited files are automatically reconsidered for recompilation.2. Track the produced *.class files, such that deleted *.class files automatically mark their originating sources for recompilation.3. Track the public API of Kotlin classes. Here we don't need anything crazily ambitious, JavaAnalyze would suffice. Kotlin classes should be treated as binary dependencies, so any changes in the public API should cause recompilation of Scala sources that depend on them.4. Track the library dependencies of Kotlin classes. If the classpath changes, Kotlin sources should be recompiled. | 21:58:25 |
| vasilmkd | Has anyone done anything similar? Any advice to share? Thanks in advance. | 21:59:33 |
| vasilmkd | * 1. Track *.kt source files and their stamps, such that edited files are automatically reconsidered for recompilation.2. Track the produced *.class files, such that deleted *.class files automatically mark their originating sources for recompilation.3. Track the public API of Kotlin classes. Here we don't need anything crazily ambitious, JavaAnalyze would suffice. Kotlin classes should be treated as binary dependencies, so any changes to a Kotlin classfile should cause recompilation of Scala sources that depend on them.4. Track the library dependencies of Kotlin classes. If the classpath changes, Kotlin sources should be recompiled. | 22:08:20 |
 zornthimmberglobber joined the room. | 22:10:42 | |
| 23 May 2024 | ||
 babawazer joined the room. | 02:09:22 | |
 im_bharadwajj | no build target found for /home/sai/MySpinalProject/hw/spinal/projectname/MyTopLevel.scala. Using presentation compiler with project's scala-library version: 3.3.3, this is the error I am getting, please look into it, as I tried to compile a scala file, it is throwing an error. | 04:49:43 |
 balmungsan3 | How are you compiling that file? What tool produced that error? | 05:07:58 |
| balmungsan3 | That doesn't look like a valid sbt project} | 05:08:07 |
| balmungsan3 | * That doesn't look like a valid sbt project | 05:08:08 |
| im_bharadwajj | i am using vscode | 05:08:30 |
| im_bharadwajj | just ruunning the files after installing metal extensions in VSCode | 05:11:54 |
| balmungsan3 | So you are not using sbt at all? Then why asking in this channel? | 05:20:53 |
| balmungsan3 | Anyways vscode can't just open a Scala file | 05:21:02 |
| balmungsan3 | It needs a build server | 05:21:07 |
| balmungsan3 | For simple programs of a single file | 05:21:14 |
| balmungsan3 | * For simple programs of a single file you may use scala-cli rather than sbt | 05:21:26 |
| balmungsan3 | https://scala-cli.virtuslab.org/docs/commands/setup-ide/ | 05:21:37 |