[Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves

Stefan Becker chemobejk at gmail.com
Tue Jun 12 19:25:57 UTC 2018


Hi Thomas, All,

On Tue, Jun 12, 2018 at 10:01 PM Thomas Petazzoni
<thomas.petazzoni at bootlin.com> wrote:
>
> I believe one of the reason we all like and use Buildroot is because of
> its simplicity. And simplicity is a very difficult thing to preserve:

IMHO this change is the very opposite of "preserving simplicity". It
adds unwanted things to the buildroot build. The unwanted things might
even be unusable for existing users of "sdk".

Please don't get me wrong. I'm not against the SDK tarball itself.

But I'm against building something for naught. If the tarball turns
out to be unusable I get slower buildroot builds. Which in turns will
force me to extract what "original sdk without tarball" was doing out
of buildroot makefile and hard-code it into my build script. And then
I can remove "sdk" from the buildroot make command. I fail to see how
that is simpler.

If you don't offer a way to specify the generated tarball name, fine.
Then I won't use sdk-tarball at all, even if the tarball itself would
be usable in our downstream integration. Or I could come up with a way
to "guess" the build artefact name in my build script and symlink it
to the wanted build artefact name (again, I fail to see how this is
simpler).

I don't understand why "sdk-tarball: sdk" is not an acceptable
solution. It would be much simpler.

Regards, Stefan

PS: just to be complete, this is what my current build script does
after "make all sdk" has been completed:

    (cd output/host && tar -cvJf ../host.tar.xz *)

The collected build artefact is "host.tar.xz". AFAIR that name can't
be changed dynamically without breaking the automatic downstream build
flow in Jenkins.


More information about the buildroot mailing list