依赖编译_方舟编译器学习笔记9 测试用例编译过程的试优化

学习笔记8 找了而一个java-core.jar，使得方舟编译器的工具链可以正常的编译helloworld。本文将继续对学习笔记7 中关于测试用例编译过程的优化进行验证和尝试。学习笔记7 中提到了在java2jar工具阶段不应该依赖java-core.jar，而只在jbc2mpl阶段依赖jar格式或者mplt的运行时库。

这种情况下，优化可以变成两个方向：1、java2jar不依赖java-core.jar， jbc2mpl依赖libjava-core.mplt；2、java2jar不依赖java-core.jar， jbc2mpl依赖java-core.jar。这两个方向都是为了将编译过程对外部的库的依赖降到最低，只在jbc2mpl阶段依赖运行时库，这样整个编译过程将会更加合理，并且简洁。

这两种思路，都需要改造java2jar这个工具，学习笔记7 提到了将java2jar改为：

#!/bin/bash
OUTPUT=$1
JAVA_FILE=$2
shift 2
javac -g -d . ${JAVA_FILE}
jar -cvf ${OUTPUT} *.class

这种情况下，java2jar已经不再依赖java-core.jar了。但是编译测试用例的过程还没做更改，所以还需要修改build/core/java2jar.mk：

$(APP_JAR): %.jar : %.java
	$(JAVA2JAR) $(APP_JAR) ${MAPLE_ROOT}/libjava-core/java-core.jar "$(wildcard *.java)"

将其中的

${MAPLE_ROOT}/libjava-core/java-core.jar

删除掉。这样，无论是在这使用java2jar，还是在编译测试用例的过程中，java2jar都不会再依赖java-core.jar了。这种情况下，我们不修改其他内容，那么这种情况下jbc2mpl还是会依赖libjava-core.mplt的，就是我们第二段文字中说的优化方向的第1种。我们这时候编译helloworld：

可以和未优化之前的执行过程做对比：

差别只是在java2jar的执行，最后生成的结果都一样。而且在java2jar生成的HelloWorld.jar的内容也完全一致。这说明我们这一步的优化是成功的，减少了重复输入运行时库，又不影响正常的编译过程。

我们再试试优化方向2，看jbc2mpl能不能直接接受java-core.jar，我们之前在分析jbc2mpl的时候知道，它是可以接受jar包的，参数改为-injar就行。那我们动手修改jbc2mpl.mk：

$(APP_MPL): %.mpl : %.jar $(JBC2MPL_BIN)
	$(JBC2MPL_BIN) --mplt $(LIB_MPLT) -injar $(APP_JAR) -out $(APP)

将其改为：

$(APP_MPL): %.mpl : %.jar $(JBC2MPL_BIN)
	$(JBC2MPL_BIN) -injar ${MAPLE_ROOT}/libjava-core/java-core.jar -injar $(APP_JAR) -out $(APP)

其实就是用原来java2jar中对java-core.jar的引用，替代了对 $(LIB_MPLT)的引用。这种情况下，我们编译helloworld:

我们可以从输出看到，jbc2mpl的执行也改变了，直接输入了java-core.jar。这种情况下测试用例也能正常的编译，但是因为jbc2mpl接受的是java-core.jar，而不是提前编译好的libjava-core.mplt文件，所以将.jar转化为.mplt的时间都加在了编译过程，所以其速度明显变慢。

上述的执行过程，证明我们想做的两个方向的优化都是可行的，尤其是第1种，效率几乎不受影响。而且通过连续几次的对编译系统以及工具链的分析，我们基本上知道了工具链的执行过程，以及整个编译系统的大致情况，可以根据自己的想法或需求去调整这些内容了。后续我们会就方舟的其他内容继续做分析。

原文链接：https://blog.csdn.net/weixin_39972777/article/details/111696236