Dear Graeme Russ,
In message CALButC+_q+bfZuMJyXjn-GbC1XFWjvGeD-go85LVUvp4S16WnA@mail.gmail.com you wrote:
I see no clean way to implement this - ok, we could provide an external tool / data base that maps boards or SoC names to CROSS_COMPILE/ARCH/PATH settings, which each user has to configure for his own set of tool chain settings.
IMHO, for running MAKEALL, I see no problem with this. If we had a 'toolchains.cfg' file which could be a format like:
#ARCH SOC BOARD TOOLCHAIN x86 sc520 - /path/to/gcc
This would give new developers a head-up as to what the defacto toolchains are
This is IMO not flexible enough. The longer I think the more I like the idea of providing a hook (script file name) that gets passed all relevant parameters as arguments (target name, arch, cpu, board name, vendor, soc, options) and that gets sourced by MAKEALL, so it is able to modify any environment variables (PATH, ARCH, CROSS_COMPILE, eventually more) as needed.
We can then have 'toolchains.cfg.local' which is added to .gitignore so individual users can override the toolchain. But all patch submissions must pass MAKEALL without using toolchains.cfg.local (something like 'MAKEALL --no-custom-toolchains'. The first thing MAKEALL should do is scan toolchains.cfg (and toolchains.cfg.local if required) for each selected arch and check that each toolchain is available and spit out 'toolchain not available' warnings.
As mentioned before: a decision based on ARCH alone is not sufficient; see for example the issues with the big endian ARM boards (PXA).
All we need to do then is setup our build machines to do an automated git-pull and MAKEALL
:-)
Best regards,
Wolfgang Denk