Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> writes: > Em Tue, Nov 26, 2019 at 05:38:18PM +0100, Toke Høiland-Jørgensen escreveu: >> Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> writes: >> >> > Em Tue, Nov 26, 2019 at 12:10:45PM -0300, Arnaldo Carvalho de Melo escreveu: >> >> Hi guys, >> >> >> >> While merging perf/core with mainline I found the problem below for >> >> which I'm adding this patch to my perf/core branch, that soon will go >> >> Ingo's way, etc. Please let me know if you think this should be handled >> >> some other way, >> > >> > This is still not enough, fails building in a container where all we >> > have is the tarball contents, will try to fix later. >> >> Wouldn't the right thing to do not be to just run the script, and then >> put the generated bpf_helper_defs.h into the tarball? > > I would rather continue just running tar and have the build process > in-tree or outside be the same. Hmm, right. Well that Python script basically just parses include/uapi/linux/bpf.h; and it can be given the path of that file with the --filename argument. So as long as that file is present, it should be possible to make it work, I guess? However, isn't the point of the tarball to make a "stand-alone" source distribution? I'd argue that it makes more sense to just include the generated header, then: The point of the Python script is specifically to extract the latest version of the helper definitions from the kernel source tree. And if you're "freezing" a version into a tarball, doesn't it make more sense to also freeze the list of BPF helpers? -Toke
