The libraries exist in two incarnations:
packed foo.klib and unpacked foo/ .
The compiler when given '-library foo' expects to find either
a foo.klib file and unpack it, or an already unpacked foo/ directory.
The stdlib is always unpacked in dist/klib .
The semantics of -o has changed slightly.
It now accepts '-o foo' and the compiler
either produces foo.kexe or foo.klib .
This patch adds 2 helpers to download dependencies for compiler and
stub generator during their execution.
They take list of external dependencies as a parameter and directory
where they must be located. Helpers check if these dependencies exist
in the given directory and download not existing ones.
Introduced LinkStage in the compiler.
Removed the link stage from 'konanc'.
Removed duplicate :stdlib and :start targets.
Simplified test run task a lot.
$ gradlew backend.native:stdlib
builds you stdlib.kt.bc now.
The test runs are taught to supply
-library stdlib.kt.bc to kotlin compiler for proper imports resolution,
and then later stdlib.kt.bc is provided to clang for the final link step.
* Remove unneeded module context creation in K2Native
Calling this method is useful only when its result is used
* Use JvmAbi from compiler instead of reflection implementation
Package "kotlin.reflect.jvm.internal.impl" is internal implementation detail of
kotlin-reflect and should not be used
* Run native back-end with "-ea"
This allows to get more detailed messages in case something fails
* Lower priority of compiler built-ins in resolution
CREATE_BUILT_INS_FROM_MODULE_DEPENDENCIES makes sure that the "built-ins" that
the compiler front-end uses during the resolution are loaded from the module
being resolved itself, i.e. from its sources and/or dependencies. E.g. if
there's a class named kotlin.Any in module sources, it'll become the default
supertype for any class without an explicit supertype.
ADD_BUILT_INS_FROM_COMPILER_TO_DEPENDENCIES adds the built-ins from the
compiler jar to the end of the dependencies list of the module being resolved.
This option makes sure that if there's no built-in class in module
sources/dependencies and it is required by the front-end, the class definition
from the compiler jar will be taken instead of failing with an exception.
If both of these options are turned on, the effect is basically that compiler
built-ins are still there in the classpath, but have a lower priority than
classes explicitly declared in sources
Nikolay Igotti