| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
scala versions
|
|
|
| |
fixes #102. Use scala js testing framework to launch tests
|
| |
|
|
|
|
| |
the `build.sc` file
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
isolated module/classloader. Most scalalib test pass, tho GenIdea is still broken
|
|
|
|
| |
Removes a lot of useless folders and gives us a chance to exercise this simplified layout. Support for the SBT layout is still verified by our integration tests
|
| |
|
| |
|
|
|
|
| |
the prefix-stripping up-front in `BaseModule`
|
|
|
|
| |
- Update `build.sc`, `build.sbt` and `ci/` scripts
|
|
|
|
|
|
| |
- Update readme and `ci/` scripts to refer to new project layout
- Remove stale `pprint.log`s
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* add generated source
* naming
* multiple content root
* no message
* fix output classes path
|
|
|
|
|
|
| |
Those tests now download a snapshot of the relevant git repo rather than vendoring the files, and use a bare `build.sc` instead of having the build object be included in the test classpath.
Tests pass using `sbt integration/test`, but `mill integration.test` still doesn't work
|
|
|
|
|
|
|
|
| |
`ScalaPlugin` -> `scalalib`, to avoid confusion with Scala compiler plugins
`ScalaModule` -> `module`, to be used via `scalalib.Module`, avoid unnecessary duplication in th name prefix
`plugin` -> `moduledefs`, to more accurately describe what it does (since it includes `Cacher` as well)
|
|
|
|
| |
paths, to fix https://github.com/lihaoyi/mill/issues/86
|
| |
|
| |
|
|
|
|
| |
of shelling out
|
| |
|
|
|
|
|
|
|
|
| |
duplication
DRY it up internally
Move the Bridge downloading logic into `shared.sc` as well, and swap the subprocesses for in-memory processing using scalaj-http and ZipInputStream
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Remove method defns for zipMap/zip that will be generated.
The trait Applyer will now extend from ApplyerGenerated which will contain the code-generated definitions.
* Script to generate code for Applicative
* Generate the zip methods in Target
* Generate zip methods in ApplicativeTests
* Make sure the full 22-arities are generated
* Move code generator into build.sc.
Remove generate.sc from directories where code will be generated.
* Generate code as part of the SBT also
* Properly wire up the test sources
* Generate all the code in one place
|
| |
|
|
|
|
|
|
| |
master branch
Remove the `out/run.sc` entrypoint script, using Ammonite's new `codeWrapper` API to synthesize the necessary wrapper/forwarder objects to substitute it
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
keyword when overriding a field within a `mill.Module`
This only applies to `mill.Module`s, not overrides elsewhere which still require the keyword. `mill.Module`s tend to have lots and lots of overriding, so the keyword is basically noise.
Also includes the necessary build changes to enable the locally-built Scalac plugin when compiling the test suite. Note that no changes are necessary for the executable assembly, because the `scalac-plugin.xml` will be included in the assembly and get picked up by the Ammonite scalac plugin classloader automatically
|
|
|
|
|
|
|
|
| |
`ReplApplyHandler` keep using the same one every time to avoid busting caches due to REPL commands being added to the classpath
Reverts https://github.com/lihaoyi/mill/pull/60, which seems to break `mill.scalaplugin.AcyclicTests.scala2123` (reproducible in master)
Tweak `build.sbt` to properly set the forked test working directory in `test-only` as well as `test`
|
| |
|
|
|
|
|
|
|
|
| |
into Mill as JVM properties.
This makes the dependency between the compiler-bridge jar and the Mill executable explicit, allowing us to swap out the locations compiler-bridge jars (which end up in different places, depending on whether you're building with SBT or Mill) or eventually making them load from Maven Central in a "release" Mill executable
Since Mill (and uTest) both do not support SBT-style test arguments, we need to use `forkTest` instead of `test` to run the Mill tests passing the compiler-jar locations as JVM props. This necessitated some fixes to make `forkTest` behave properly
|
|
|
|
| |
jars get build for use by the executable
|
|
|
|
|
|
|
|
|
|
| |
cross-minor-version `AcyclicTests` running using the `mill` test runner
Fixed `Discovered` to only pick up public `Target`s, which makes it skip things like the `super$compile` of an overriden `compile` target.
Split up `sources` and `allSources`
TBD how to properly switch the `compilerBridgeJar` between the different output paths of SBT's compile-dir and Mill's compile-dir, and eventually to a maven-central artifact too
|
|
|
|
|
|
| |
compiler-bridge.jar.
For now just hardcode the Scala versions we want to support as part of the build; we can figure out how to do the runtime download&compile thing later
|
| |
|
| |
|
|
|
|
| |
to use anyway due to Ammonite. Saves us from classloading play-json and Jackson, shaving off a few hundred ms from the cold no-op runtime
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
generate routes purely based on a type `T`, as part of the target discovery process. We defer the need for a concrete value of type `T` later until we need to evaluate the route.
Eventually this should go upstream into ammonite itself, but forking is easier for now
|
|
|
|
| |
cycles exist
|
|
|
|
|
|
| |
the `T#apply` macro in the implementation of `scalaplugin.Subproject`
Also needed to implement inter-`Subproject` dependencies so the `MetacircularTests` can continue to support the new layout
|
|
|
|
| |
doesn't compile
|
| |
|