search

deanwampler / programming-scala-book-code-examples

The code examples used in Programming Scala, 2nd and 3rd Editions (O'Reilly)
Other
642 stars 407 forks source link

IntelliJ Build Issue With Compiler Flags Settings #38

Open cedarbob opened 2 years ago

cedarbob commented 2 years ago

I get the following build error when I try to run any of the introscala examples (and I assume any of the examples):

scalac: Flag -encoding set repeatedly

I'm attempting to run by simply selecting one of the main methods and electing "run XYZ" in the popup menu with the default scala compiler options in the IDE. I also tried commenting out the "-encoding", "utf-8" scalac option in build.sbt but got the same result.

cedarbob commented 2 years ago

However, I was able to run Hello, Hello2 via sbt in a terminal window without any problem.

cedarbob commented 2 years ago

After doing this, the IDE prompted me to reload project changes, which I did. I then repeated my original test by selecting the code for Hello2 in UpperMain2.scala and electing "run Hello2" from the popup - and got a different build error:

/home/rhr/Test/programming-scala-book-code-examples-master/src/main/scala/progscala3/typesystem/bounds/list/AbbrevList.scala:36:18 @targetName annotation "AbbrevListCons" clashes with other definition in same scope final case class ::[B](private var hd: B,

ddl-deanwampler commented 2 years ago

Thanks for the bug reports. I'm leaving a short vacation. I'll look at them when I return.

deanwampler commented 2 years ago

I didn't use IntelliJ to develop the examples. It appears the second definition of -encoding foo is in the IntelliJ compiler preferences. To fix:

  1. Open the preferences (cmd-, on MacOS)
  2. Search for "scala"
  3. Select "Build, Execution, Deployment > Compiler > Scala Compiler"
  4. Select the "sbt" configuration in the list of Scala build configurations.
  5. Select "Additional compiler options:".
  6. Remove -encoding utf-8 from the text.

After that, I could select a type with a main and run it.

If you still get the "clashes" error, try running sbt clean in a terminal, then let IntelliJ build the software. I suspect you had two target directories, one created by IntelliJ and one created by SBT and both ended up on the class path.

I'll put these comments in the project README, too.

deanwampler commented 2 years ago

I did see the @targetName clash when I attempted to use SBT's console in IntelliJ's set shell, while I don't see it when I use sbt console in a separate terminal window. I think that adds weight to my theory that there are two copies of all the classes on the class path, although I didn't investigate further. What works for me is to use sbt console in a terminal window only.