Add a library dependency to all compileInterface sub projects

[Martin Duhem]

Hi,

As I was saying in the thread Record dependencies of macro expansions, we have a compiler plugin that tracks all the symbols that are touched during the expansion of a macro, and then attaches them to the expansion.

What I would like to do is to get back these attachments from the trees.To do this without using reflection, we wrote a small library that is cross compiled against all the Scala versions that are used in the compiler interface SBT sub projects. That is, Scala versions 2.8.2, 2.9.2, 2.9.3, 2.10.4 and 2.11.0.

I am now trying to add this library as a dependency of the compile interface sub projects, but I am facing a few problems.

What I have done is : 

1. Add this at the end of `precompiledSettings` :
   libraryDependencies += "org.scalareflect" %% "scalahost-runtime" % "0.1.0-SNAPSHOT" cross CrossVersion.full
   
2. Add this at the end of `compileInterfaceSettings` :
   libraryDependencies += "org.scalareflect" %% "scalahost-runtime" % "0.1.0-SNAPSHOT" cross CrossVersion.full
   

The problem is that, after running `update`, the following error occurs : 

[error] Modules were resolved with conflicting cross-version suffixes in {file:/Users/martin/Documents/Projects/Duhemm/sbt/}sbt:

[error]    org.scalareflect:scalahost-runtime _2.11.0, _2.9.2, _2.10.4, _2.8.2, _2.9.3

The problem comes from the project `sbtSub` that depends on `compileInterfaceSub` and all the `precompiled2xx`. As a result, `sbtSub` will depend on all these different versions of `scalahost-runtime`.

Unfortunately, this library must be cross compiled for each version of Scala. Using a generic version won't work since it uses, among others, `Attachments` that seem to have been moved around in the Scala compiler.

Is there a way to make use of this library in this subproject ? Thank you !

[Grzegorz Kossakowski]

Hi Martin!

Adding dependencies to the compiler-interface subproject is going to be rather difficult. The reason is that compiler-interface is shipped in two forms:

• precompiled
• as source code

In the second form, the sources from the jar are compiled on the fly when there's no precompiled version around. It means you'd have to ship your small library as source artifact too and make sure that this jar is added to the source path when compiling on the fly. If you want to support just the precompiled scenario then it's also problematic. The reason is that sbt uses it's own internal logic to resolve the jar for the compiler interface and that logic assumes that this jar has no dependencies. See:

https://github.com/sbt/sbt/blob/0.13/compile/ivy/src/main/scala/sbt/compiler/ComponentCompiler.scala#L20

That method returns path to just one jar. You'd have to modify that code and everything that uses that code to work with dependencies of compiler-interface.

Have you considered the other route: making it configurable in sbt project the name and the group id of the artifact for the compiler-interface jars?

This way you could ship your own fork of compiler-interface jars from project Palladium and plug them into sbt projects in such way:

compilerInterfaceDependency := "org.scalareflect" % "palladium-compiler-interface" % "0.1"

Your version of compiler-interface could implement all the logic you need in a single jar. I'd be open to making it configurable how to resolve the compiler-interface jars.

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/e366dba6-bec7-4a9e-aed2-df38433cb4dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Eugene Burmako]

Maybe there could be another, seamless way of achieving this? I mean, this starts looking a bit too much in comparison with a solution that just casts its way to the list of symbols stored in an attachment.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAD%2BExrL7PnOnxZpWdMfWjKWb9rCsycuWXKZpnhVr56-YhN9T8g%40mail.gmail.com.

[Grzegorz Kossakowski]

On 2 May 2014 13:46, Eugene Burmako <eugene....@epfl.ch> wrote:

Maybe there could be another, seamless way of achieving this? I mean, this starts looking a bit too much in comparison with a solution that just casts its way to the list of symbols stored in an attachment.

I don't understand what are you proposing. Are you talking about casting to structural types which involves reflection?

[Martin Duhem]

I think Eugene was referring to what he suggested to me last Friday : storing the list of touched symbols as a `Map[String, Any]`. This way we can simply retrieve the touched symbols with something like `attachment.get("touchedSymbols").get.asInstanceOf[List[Symbol]]`.

[Grzegorz Kossakowski]

I agree that's probably the way to go while you are experimenting.

--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/449e0877-1d70-4053-b3ec-9cfca138ca25%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.