Opinion about SDK extensions

[FedericoVaga]

By default, in the SDK we get the C and C++ toolchain. From the XML project file we can add more tools to the SDK. However, this can't be done after the SDK got generated. On one hand, it is impractical to add all possible tools to the host SDK. On the other hand, it could be handy to extend an existing SDK with new packages, depending on the need.

The use case would be, for example, adding building tools like cmake or meson, or additional python packages used during the building process. This for users who want to rely uniquely on the SDK and not on their computer to provide these tools.

I understand it is not trivial due to the SDK relocation. However, I'm wondering if it could be a useful feature to add. What do you think?

[t-8ch]

The way the SDK installer is set up makes it hard to modify it after the fact.

I'm not sure about "it is impractical to add all possible tools to the host SDK", how many do you imagine?
Or are the SDK users unknown to you?

It should be possible to create an SDK per additional buildtool and either install all of them to the same directory or use them through $PATH modifications.

[FedericoVaga]

Hi @t-8ch, you guessed right when you said that users are unknown to me. As of today, in our working environment there is not a strict guideline, and this implies users' freedom.

As of today, I do not see any concrete issue in not providing additional tools in the hostsdk. What matters is that compiled code gets produced with the same compiler used to build the image. But the origin of tools like make, meson, cmake, ninja, python-this, perl-that should matter less, and these tools can come from the developers' environment without creating problems.

On the other hand, I understand developers when asking for having all tools preinstalled. Similar requests then push in the direction of building an environment-* script containing variables for the preferred tool, and sometimes also additional files.

What do you think?

[t-8ch]

As of today, I do not see any concrete issue in not providing additional tools in the hostsdk.

With this you mean embedding external tools into the SDK?
Embedding something after the fact is technically hard.

If you mean embedding them as part of the normal build process, sure it's meant to be used that way.

and these tools can come from the developers' environment without creating problems.

This depends on the concrete tool in question.

You could provide two SDKs. One minimal which the user can extend themselves with tools from their environment and one with everything included.

[FedericoVaga]

As of today, I do not see any concrete issue in not providing additional tools in the hostsdk.

With this you mean embedding external tools into the SDK?
Embedding something after the fact is technically hard.

If you mean embedding them as part of the normal build process, sure it's meant to be used that way.

I mean this, but I also mean NOT doing that and letting the user pick mason,ninja, rsync, etc from their working environment.

and these tools can come from the developers' environment without creating problems.

This depends on the concrete tool in question.

Indeed. Clearly if clang or other compilers must be provided they must go in the hostsdk list.

[t-8ch]

I mean this, but I also mean NOT doing that and letting the user pick mason,ninja, rsync, etc from their working environment.

The SDK is not a sandbox, so you should be able to fiddle with PATH to access the host tools.