I’m testing AxLang, a blockchain language based on Scala (http://axoni.com/axlang), and would like to run Partest against our compiler, initially just the negative tests. If I change compilerUnderTest and the "compiler" case in findArtifact() in partest/scala/tools/partest/nest/FileManager.scala, and then run Partest, the output says that “Compiler under test:” has changed, and DirectCompiler.scala says that that scalac has been invoked. But “scalac” in the message seems to be a hard-coded string, and what execCompile() does immediately after the message seems to be quite different. Is there a better place to change the compiler under test, preferably by giving it the path to our compiler?
The string is correct, for certain values thereof: it’s meant to show the putative command line by which scalac is being executed. In reality, as you’ve noticed, we only pretend to do that; partest apparently just uses whatever scalac is on its classpath.
Is AxLang a compiler plugin, or a library that invokes scalac programmatically? We used to have -Yglobal-class which possibly could have helped here, but that seems to have been cut.
A patch to partest to allow for more ways to specify how the compiler is invoked wouldn’t necessarily be rejected outright.
That all said, partest – like the rest of the Scala library and compiler – is libre software licensed under the Apache License: if you can comply with its generous terms, there’s nothing stopping you from copying partest’s sources into your test suite and modifying DirectCompiler#compile to invoke axc or whatever however is appropriate for you. By the time partest has gotten there, you’ve got a list of files and a list of scalac options, which hopefully will be all you need.
(This is the bit where @som-snytt shows up to tell me how wrong I am and how easy your question is, if you just know the secrets…)
1 Like
Is AxLang a compiler plugin…?
Yes, the frontend is; it talks to our backend.
there’s nothing stopping you from copying partest’s sources into your test suite and modifying DirectCompiler#compile to invoke axc
Thanks, that’s probably what I’ll do first.
A patch to partest to allow for more ways to specify how the compiler is invoked wouldn’t necessarily be rejected outright.
That’s what I’d like to do in the long run, both to be good open source citizens, and to avoid merge conflicts when we pull. We’ll eventually also need to specify a script to deploy and run the output from the compiler (as would users of Scala on embedded systems, if there ever are any). Would adding Test Runner Options called compilerpath and runnerpath be the right interface?