If I build a "classic sdk" autotools (aclocal, autoconf, automake) are part of it. If I build from the same meta data an "extensible sdk" autotools are missing. If I install buildttools-extended it seems to work. Is this intentionally?
Likely intentional but Saul will confirm.
cmake is in the extensible SDK.
What bothers me here is that classic and eSDK suddenly behave differently. If this is really intentional it should be documented somewhere.
I am not sure this is sudden, it's been this way from the beginning, when eSDK was first introduced. There was a mechanism that shared the TOOLCHAIN_HOST_TASK list with populate_sdk, but it is overridden in the populate_sdk_ext class. The various nativesdk-* binaries are installed as rdepends within populate_sdk, but never were in the eSDK.
From my tests it looks like autotools is part of the SDK and was part of the eSDK until honister. There was no need to source the buildtools extended script before honister in order to get autotools to work. If autotools are supposed to be part of buildtools extended, I'm fine with that.
cmake-native being in there is interesting, but most likely unintentional: it just followed the dependencies of whatever the default build target in a non-minimal eSDK is. Minimal eSDKs don't ship with a sysroot at all. Either way, you can install autoconf trivially: $ devtool sdk-install autoconf-native INFO: Installing autoconf-native... INFO: Successfully installed autoconf-native $ which autoconf /home/ross/Mess/esdk/tmp/sysroots/aarch64/usr/bin/autoconf
bulk change to add Saul's non-WR address.
Bulk change: Remove Saul's old WR address.