BTW I've made progress on the readonly issue. Looks like they have changed the name of the config variable in crosstool-NG. It's now called CT_PREFIX_DIR_RO instead of CT_INSTALL_DIR_RO so the sed command in the Makefile finds nothing.
I've also been talking to one of the crosstool maintainers, who was kind of horrified with our ESP8266 approach to creating a customised config file, but I'm still trying to get a way to run
ct_ng menuconfig
Having said that, they've come up with quite a few really good points and I think a review of our Makefile and build process is in order:
- sysroot based toolchains for 'bare metal' (ie. Non-OS based) systems were removed in 1.22 because there was unnecessary and incorrect duplication of include and lib structures.
- our current Makefile pollutes the crosstool-NG tree and doesn't completely clean up after itself
- the current xtensa build process patches source code in place, making it impossible to build the same toolchain for different architectures (eg. esp8266 and ESP32) without doing a full clean
- the current toolchain directory format could be changed so that multiple architectures are supported file structure
I'm thinking of having a go at refactoring the Makefile to accommodate this - do you think this is useful?
davydnorris wrote:- sysroot based toolchains for 'bare metal' (ie. Non-OS based) systems were removed in 1.22 because there was unnecessary and incorrect duplication of include and lib structures.
I'm not sure about that, but I didn't have enough time for a good look at it. My current impression is that it complicates the setup (supporting two configurations: sysrooted and non-sysrooted instead of one) and makes it less flexible (one cannot pass --sysroot option to the components of non-sysrooted toolchain).
davydnorris wrote:- our current Makefile pollutes the crosstool-NG tree and doesn't completely clean up after itself
- the current xtensa build process patches source code in place, making it impossible to build the same toolchain for different architectures (eg. esp8266 and ESP32) without doing a full clean
The crosstool-ng is a throwaway in that process anyway. And from my experience configuration switch works correctly without an explicit full clean.
davydnorris wrote:I'm thinking of having a go at refactoring the Makefile to accommodate this - do you think this is useful?
If that's the esp-open-sdk Makefile then it's probably a good question for Paul.