Use the latest IntelliJ release.
Make sure the Scala plugin is installed. (It may come preinstalled; if not, install it before proceeding.)
Do not attempt to import our sbt build into IntelliJ; it won't work.
Instead, create IntelliJ project files as follows.
sbt intellij
The project files are created as copies of the .SAMPLE
files, which are under version
control. The actual IntelliJ project files are in .gitignore
so that local changes
are ignored.
Then to start coding:
src/intellij/scala.ipr
in IntelliJBuild
menu, choose Build Project
Everything (library, compiler etc) should build within a few minutes.
Recent versions of IntelliJ are able to find a JDK on your system and select it automatically. If that doesn't happen:
File
→ Project Structure
→ Project
→ Project SDK
, create an SDK entry
named "1.8" containing the Java 1.8 SDKNote that 8 is the safest choice. If you're having trouble, you might check to see if IntelliJ selected some later version.
If you often work on both the 2.12.x and 2.13.x branches, the safest approach is to have a separate clone of the repository for each branch.
(But if you find that switching works even in the same clone, consider submitting an update to this readme with any advice you have on this.)
Note that compilation IntelliJ is performed in a single pass (no bootstrap), like the sbt build.
Note that the output directory when compiling in IntelliJ is the same as for the
sbt build. This allows building incrementally in IntelliJ
and directly using the changes using the command-line scripts in build/quick/bin/
.
JUnit tests can be executed by right-clicking on a test class or test method and selecting "Run" or "Debug". The debugger will allow you to stop at breakpoints within the Scala library.
It is possible to invoke the Scala compiler from a JUnit test (passing the source
code as a string) and inspect the generated bytecode, see for example
scala.issues.BytecodeTest
. Debugging such a test is an easy way to stop at
breakpoints within the Scala compiler.
You can create run/debug configurations to run the compiler and REPL directly within IntelliJ, which might accelerate development and debugging of the compiler.
To debug the Scala codebase you can also use "Remote" debug configuration and pass the corresponding arguments to the jvm running the compiler / program.
To run the compiler create an "Application" configuration with
scala.tools.nsc.Main
-usejavacp -cp sandbox -d sandbox sandbox/Test.scala
compiler
To run the REPL create an "Application" configuration with
scala.tools.nsc.MainGenericRunner
-usejavacp
repl-frontend
For every module in the IntelliJ project there is a corresponding -deps
library, for example compiler-deps
provides JARs for the compiler codebase.
The .jar
files in these -deps
libraries can be easily kept up-to-date by running sbt intellij
again.
This is necessary whenever the dependencies in the sbt build change, for example when the starr
version is updated.
Note that this command only patches the dependency lists, all other settings in the IntelliJ project definition are unchanged.
To overwrite the project definition files by copying the .SAMPLE
files again run sbt intellijFromSample
.
.SAMPLE
filesThe command intellijToSample
overwrites the .SAMPLE
files using the current project definition files.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )