关于 JerryScript 的建议

[chunhuajiang]

非常开心看到对 GCC 的支持了，且在 Makefile 里面看到 JerryScript 的影子了。

进一步看 Makefile 的源码，发现当前是将 JerryScript 和 LiteOS 放在同一层次的目录下的，建议可以将 JerryScript 作为 LiteOS 的一个子模块，用 git submodule 来维护，这是当前比较流行的做法，比如 Contiki、zephyr.js、乐鑫的 ESP-IDF 等都是采用的这种做法。

[BaikalHu]

谢谢你的关注，在https://github.com/jerryscript-project/jerryscript/tree/master/targets/riot-stm32f4 中riot或者nuttx中，都是将JerryScript和OS源码放在同一层次的目录下进行编译的。 目前的做法在JerryScript下的targets建立LiteOS-stm32f4目录，然后用类似的方法来集成LiteOS和JerryScript。

[chunhuajiang]

@BaikalHu
我的个人见解是，使用 git submodule 便于项目维护，只对开发者可见，对用户是不可见的。 这样用户只需要看到 liteos 一个仓库，而不需要同时看到 liteos 和 jerryscript 两个仓库。

• 三星官方 IoT.js 的做法也是通过 submodule 来管理的： https://github.com/Samsung/iotjs/blob/master/.gitmodules
• Zephyr.js 也是通过 submodule 来管理的：https://github.com/01org/zephyr.js/blob/master/.gitmodules(虽然我们也能在jerryscript的 targets 目录下看到zephyr)
• riot我没研究过，不过据我了解它是通过 pkg 来管理它所依赖的包的，刚刚简单地看了下riot的pkg的本质，它应该也是在riot目录里面安装的 jerryscript，用户依然只见到 riot 这一个仓库 https://github.com/RIOT-OS/RIOT/blob/master/pkg/jerryscript/Makefile
• 另外，本人之前还有一个残废品 esp.js 也是通过这种方式的 :smile: 。（PS:本来是想自己根据liteos搞个lite.js的，但是研究了jerryscript，发现它只支持linux，而liteos不支持gcc，故而转战esp32）

我个人理解，jerryscript里面的 targets 目录下面的子目录，应该是用于提供一个 demo。