Open megri opened 7 years ago
Those TypeTag[whatever]
also feel like a leaky abstraction. Something should probably be done with those before considering a merge.
Using one of the approaches mentioned here might do the trick: https://stackoverflow.com/questions/23785439/getting-typetag-from-a-classname-string
so what's not working yet?
I am still a little concerned about performance with this and is scala reflection thread safe these days?
I've updated the prototype and I'm now confused. It seems to partially work! But why? I've basically bludgeoned def taskMethods
into frankenstein's method.
There seems to be some issues with calling tasks defined in the CBT scope at the moment — not sure why.
I believe scala reflection is still not thread safe. time cbt
on a compiled project shows cbt 0,04s user 0,07s system 20% cpu 0,539 total
on my Macbook Pro anno 2012.
Comparison of running cbt
on a simple project
before
Methods provided by Build(/Users/martin/dev/scala/cbt-test/splaintest)
dontShowMe sausages
Methods provided by CBT (but possibly overwritten)
_context buildInfoXml c classLoader classLoaderCache classes classpath clean cleanFiles compile compileClasspath compileDependencies compileStatusFile compileTarget complete context crossScalaVersionsArray defaultScalaVersion dependencies dependenciesArray dependencyClasspath dependencyClasspathArray dependencyTree docTarget enableConcurrency exportedClasspath exportedClasspathArray finalBuild flatClassLoader fork generatedSources getClass hashCode help jarTarget lastModified lib libraries localJars logger mainClass mainClassOrFail moduleKey name needsUpdateCompat nonEmptySourceFiles notify notifyAll ports projectDirectory publish r recursive repl resourceClasspath restart rt run runForked runForkedHandles scalaMajorVersion scalaTarget scalaVersion scalacOptions scaladoc show sourceFiles sources t target targetClasspath taskCache test toString transientCache transitiveDependencies triggerLoopFiles triggerLoopFilesArray verifyClasspath void wait zincVersion
after
Methods provided by Build(/Users/martin/dev/scala/cbt-test/splaintest)
sausages
Methods provided by CBT (but possibly overwritten)
artifactId buildInfoXml c classLoader classes classpath clean cleanFiles compile compileClasspath compileStatusFile compileTarget complete context crossScalaVersionsArray defaultScalaVersion dependencies dependenciesArray dependencyClasspath dependencyClasspathArray dependencyTree description developers docJar docTarget enableConcurrency exportedClasspath exportedClasspathArray finalBuild flatClassLoader fork generatedSources groupId help inceptionYear jar jarFilePrefix jarTarget lastModified licenses localJars mainClass mainClassOrFail moduleKey name needsUpdateCompat nonEmptySourceFiles organization package pom projectDirectory publish publishLocal publishedArtifacts r recursive repl resourceClasspath restart rt run runForked scalaMajorVersion scalaTarget scalaVersion scalacOptions scaladoc scmConnection scmUrl show sourceFiles sources srcJar t target targetClasspath test toString transientCache transitiveDependencies triggerLoopFiles triggerLoopFilesArray url verifyClasspath version void zincVersion
Could this be achieved with something similar to ammonite's router ?
IE, when compiling the build, a macro could take care of aggregating the callable methods into a router that effectively acts as a single entry point to cbt. I assume this would create overhead when compiling the build would allow for safer method calls, allow for calling methods with arguments from the terminal
As things currently stand, running" for accessible members of Build but a whole bunch from CBT
cbt
shows "