Dear Stephen Warren,
In message 51A68A4C.4060505@wwwdotorg.org you wrote:
Sorry, instead we should strive to be compatible to a reasonably old, stable version of DTC, like we do for all other tools as well. As mentioned before - just because RHEL 5 ships an ancient version of - say - "make" we will NOT start building this from the sources ourself. This cannot be the way to go.
So the result of that is that we can never ever use new features in any tool, at least in any meaningful time-frame.
I wrote "we should strive", not "this is the only way".
However, when enabling a new feature, such as using device trees to configure U-Boot[1], for which tool support is new and evolving along with the feature itself, and which is only used on a very very few boards and even fewer SoCs right now within U-Boot, it seems entirely reasonable to demand that the people working on/with that new feature are aware that it's evolving, and that they may need to take a few extra steps to go out and get tools that support that new feature. No doubt once this feature has settled down a bit, and distros have pulled in newer versions of dtc, everthing will "just work" just like any other stable feature.
Agreed. And nothing prevents you to installl on your system another, more recent version of dtc or any other tools needed for specific purposes.
If you don't accept this, then we simply have to ban any include use in U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to
This has never been my intention. I object only against including the dtc source into U-Boot, and against automatic methods to build dtc as part of U-Boot, even in a way that depends on the U-Boot version.
dtc is a tool, like gcc or others. We may test against specific versions of the tools in the Makefiles, and even abort a build if an incompatible version is found. But we will not include tool sources, nor build / install rules for tools.
Best regards,
Wolfgang Denk