We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
非常开心看到对 GCC 的支持了,且在 Makefile 里面看到 JerryScript 的影子了。
进一步看 Makefile 的源码,发现当前是将 JerryScript 和 LiteOS 放在同一层次的目录下的,建议可以将 JerryScript 作为 LiteOS 的一个子模块,用 git submodule 来维护,这是当前比较流行的做法,比如 Contiki、zephyr.js、乐鑫的 ESP-IDF 等都是采用的这种做法。
The text was updated successfully, but these errors were encountered:
谢谢你的关注,在https://github.com/jerryscript-project/jerryscript/tree/master/targets/riot-stm32f4 中riot或者nuttx中,都是将JerryScript和OS源码放在同一层次的目录下进行编译的。 目前的做法在JerryScript下的targets建立LiteOS-stm32f4目录,然后用类似的方法来集成LiteOS和JerryScript。
Sorry, something went wrong.
@BaikalHu 我的个人见解是,使用 git submodule 便于项目维护,只对开发者可见,对用户是不可见的。 这样用户只需要看到 liteos 一个仓库,而不需要同时看到 liteos 和 jerryscript 两个仓库。
我个人理解,jerryscript里面的 targets 目录下面的子目录,应该是用于提供一个 demo。
BaikalHu
No branches or pull requests
非常开心看到对 GCC 的支持了,且在 Makefile 里面看到 JerryScript 的影子了。
进一步看 Makefile 的源码,发现当前是将 JerryScript 和 LiteOS 放在同一层次的目录下的,建议可以将 JerryScript 作为 LiteOS 的一个子模块,用 git submodule 来维护,这是当前比较流行的做法,比如 Contiki、zephyr.js、乐鑫的 ESP-IDF 等都是采用的这种做法。
The text was updated successfully, but these errors were encountered: