Outdated or incorrect build instructions for several targets

[akosthekiss]

During the scripting of target build test automation for Travis CI (#2102), several issues have been identified:

• ESP8266:
  • The apt dependencies list was overly extensive (at least compared to what Travis CI had already installed on the worker image), sometimes even erroneous (e.g., didn't have to install any libc6-dev* packages and actually couldn't install libtool-bin because such a package was not available).
  • The creation of the /opt/Espressif directory is described together with the dependencies step although it belongs to the crosstool-NG building step. Moreover, it should be noted that neither the building of ct-ng nor the execution of ct-ng to build a cross toolchain requires elevated privileges (it can be done somewhere in the user's home directory, not under /opt only).
  • Building crosstool-NG didn't work for me exactly as described, make detected recursion and bailed out.
  • When building the firmware with JerryScript, why must BIN_PATH be specified? Couldn't it have at least a default to be the same as BUILD_DIR?
• Mbed OS 5:
  • The target needs heavy maintenance. As is, building an example app or a library from sources present under targets/mbedos5 with the Makefile is not possible. make all errors because there is no main in the code base, make library errors because launcher sources require jerry-targetjs.h that are explicitly not generated for libraries. Then the readme suggests to do a gulp-based build, but that build system uses a pinned JerryScript version (https://github.com/ARMmbed/mbed-js-gulp/blob/master/main.js, const JERRYSCRIPT_REVISION = '5cdb98c75ec231806677a8af0b16d508b1033eb2';) not master. So that seems never building with latest jerry. The target should always be able to test latest developments.
• NuttX:
  • The readme doesn't mention which version of NuttX was last seen working. (7.22 worked for me, see makefile.)
  • The readme doesn't describe how configuration can be automated (without menuconfig that requires user interaction). Moreover, the readme suggests fetching the kconfig sources from a "3rd party" while the nuttx/tools repo contains its own kconfig sources.
• Particle: I couldn't get it to build at all.
• RIOT:
  • The readme doesn't pin the last known working version of RIOT. (2017.10 worked for me.)
• Tizen RT:
  • The readme doesn't pin the last known working version of Tizen RT. (1.1_Public_Release worked for me but only if I adapted the romfs patch.)
  • PPA-based GCC6 version worked, too (readme mentions GCC4.9, but that just seems to be a lower bound, not a must).
• Zephyr:
  • The readme doesn't pin the last known working version of Zephyr, which is quite an issue. Zephyr has changed build system on master to something cmake-based, which is completely incompatible with the code in targets/zephyr right now. For me, Zephyr 1.9.1 and Zephyr SDK 0.9.1 worked. (But even in this release, Zephyr doesn't seem to have the readme-suggested qemu make target anymore.)
  • Non-interactive installation required quite some recursive digging into self-extracting archives within self-extracting archives, because documentation suggests interactive installation of the SDK by "ansering all questions" (out of question on Travis).
  • Directory structure suggested by readme has zephyr-project, although when I clone it out from github, it will be named zephyr by default.
  • Calling make with ./targets/zephyr/Makefile.zephyr fails to build the JerryScript library with quite weird errors... unless you set CC to point deep within the Zephyr SDK: zephyr-sdk-0.9.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc. Which is not documented anywhere and was a hell to debug. Note: zephyr sets its the build environment for its own build system up by sourcing zephyr-env.sh, but JerryScript's build system will know nothing about that. And Makefile.zepyhr will use $CC which is usually still set to the native compiler.

It would be great if target maintainers could check these out.

[akosthekiss]

A related issue, but not documentation related: calling make from makefiles is preferably done via $(MAKE) note make. Quote from the GNU make manual:

Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’

Explanation can be found here: https://www.gnu.org/software/make/manual/make.html#MAKE-Variable

Affected makefiles: Makefile.{esp8266,mbed,particle,riot,tizenrt,zephyr}

[yichoi]

I would like to select again official targets again to focus our resources.